Why use Tasks?

As we coach software development teams in Kansas City, we are often asked about the process of breaking User Stories down into development tasks (anything related to implementing and verify a User Story). This is one of the areas teams struggle with when adopting an Agile process. It's actually something they often struggle with using most any process but most Agile approaches rely heavily on it for a number of reasons.

1) Iteration Planning

Tasks are a good last check for iteration planning purposes. Even though we can rely (to some extent) on past  actual velocity to get a sense of what a team might be able to achieve in subsequent iterations, breaking stories down into development tasks/hours allows the team to leverage what they've learned so far during a given release in terms of some stories being potentially larger or smaller than previously thought. They can use that information to develop a better, more reliable/realistic iteration plan.

During planning, openly discussing development tasks gives all team members a view of what will take place while implementing the stories selected for the iteration. During that discussion they can help each other clarify and improve their development plan and discuss lesser known areas of the code, database, etc. to help other team members learn and become more productive in their development.

2) Iteration Burndown (what's left <how many hours> to do within a given iteration)

Having tasks with hours estimates enables the team to discuss (during the Daily Stand Up meeting) why certain tasks might be taking longer than planned, why some tasks were overlooked when a story was initially discussed, why some tasks weren't ultimately needed. With this information, it becomes apparent that at times, developers may be struggling with a given task and may need help.

It also enforces thinking more thoroughly about tasks needed to complete a story and aides in becoming better at tasking and task estimating during subsequent iteration planning meetings. It also allows the team to get an earlier sense of whether the goals and story points planned for a given iteration will be achieved and allows the team to consider adjustments sooner.

3) Accountability

Defining and estimating tasks makes team commitments to an iteration public knowledge and increases
the sense of urgency of getting better at task definition and estimation. It also can help with maintaining a sense of focus on agreed upon tasks and indirectly trims waste related to gold plating. It can encourage team members to seek assistance on tasks they might be struggling with as their 2-hour task still isn't done after a couple of days effort while the teams velocity begins to become negatively impacted.

Developing for a story without tasks can lead to stories that don't get done or done as hoped. Without tasks, the team loses the ability to provide assistance (since nobody knows what you're doing) and overall iteration and ultimately release predictability suffers.

4) Shared and Individual Learning

Discussing, defining, estimating and tracking tasks allows the entire team to learn about the problem domain, especially when the domain or parts of it might be new to certain team members. It also helps all team members become better about planning the work needed for all stories and helps them to become better definers and estimators of tasks.

5) Tasking Encourages Better Design

Thinking through a plan of attack for implementing user stories and creating steps (a.k.a tasks) to achieve it tends to create a higher level of focus and optimize overall productivity. It also facilitates design discussion often resulting in better and more complete story implemenation.

6) Forecasting Velocity

When you don't have the luxury of running an iteration to get an actual velocity but need to provide stakeholders with some sense of cost and schedule, you need to forecast the teams velocity. Using tasks is very effective for this. Do this by estimating team capacity, breaking stories down into tasks/hours until the capacity is filled and adding up the points for the stories you just tasked. You now have a forecasted velocity to provide a preliminary forecast of cost and schedule.

7) Tasks Serve as Reminders

When you task, typically at the beginning of an iteration (during the planning meeting), you have the users  attention and are able to ask questions to which you'll need answers to enable you to think about your plan of attack for a given story in terms of development tasks that will be necessary. Even a few days into the actual iteration, you'll forget at least part of what you discussed with the user if you don't have recorded tasks and you'll have potentially less access to the user to confirm/reconfirm tasks and/or stories.

8) Talk to the Dog

Having to talk out loud and/or in a public setting about tasks you'd need to complete a user story tends to create greater focus than just beginning to code. It typically creates better overall productivity and thoughtfulness in approaching the implementation of a story.

9) What if you hear, "I can't/won't task."?

If a team or team member simply says they won't task, that's more of a personal discussion. Obviously asking them why they won't task would be a useful starting point, it may ultimately speak more to ego, personality or an underlying resistance to change.

When a team or team member claims they can't task you have more information to work with. A common stated reason is that they "just have to start coding" and don't really know about the tasks until they start working on it. One approach is to say "Fine, then write down the tasks as you uncover them during coding and we'll discuss and learn from those to make you a better up-front tasker.". You can also allow a "research" task (2-4 hours) to allow a developer to spend time looking at the code, database, etc. for purposes of ultimately tasking a user story.

Above are just a few broad reasons why tasking is useful for software development, in particular for Agile processes.

Ask for a general question, get a general commitment.

I don’t know if this has ever happened to you, but when you are in the middle of a project (not even a business project, but say coordinating some volunteers for an event) and you ask around for help in general terms.  You know the conversation it sounds something like “Hey Jan. I’m heading up the refreshments for next weeks Scout meeting.  Would you like to help by bringing some cookies or maybe help setting up?”  Usually the people you talk to agree to these general commitments.  After two or three conversations like this you start feeling good about the project and have a sense that you’re going somewhere.  Then it hits you, all you’ve done at this point is ask two or three people if they are interested enough in what you are doing, to possibly take part in it.  At this rate, you could have ten people ready to help and waiting for further instructions in no time.

What really needs to happen is you have to have a plan, even a rough one, at the outset. With some sort of a plan, you can ask for a specific commitment like “Jan we need refreshments for next week’s Scout meeting. Would you be able to bring two dozen cookies on Tuesday night?”  After asking this, you wait for an answer (a specific commitment.) Then if you need to you can follow up with “Great! Thanks.  Also we will be setting up for the meeting at 6:45, can you be there to help?”  This benefits both you as the coordinator since you have a better idea of what to expect, and the person you are asking as they have a clear idea of what is expected from them.  It’s a simple concept that sometimes gets lost. The problem is that when it’s lost, you eventually have to go back and ask everyone that gave a general commitment for a specific commitment.  

I was reminded of this earlier this week when talking to one of Visionpace’s .Net development teams.  The conversation was concerning code coverage for our unit testing and my initial question to the team was “Are our coverage and testing scenarios sufficient for these user stories?”  Just as I asked the question, I realized it was too general.  Before I could rephrase the question, another teammate spoke up for me and said, “I think what Martin is asking is two questions. A) What is the percentage of coverage we have for the different modules on the project? B) Are we testing the ‘happy path’, boundary conditions and ‘unhappy paths’ for all unit tests?” He was right. His questions got to the specific meaning of what I wanted to know and he asked questions that the developers could give specific answers to.  Had the questions not be rephrased, I’m sure I would have gotten the equally general answer of ‘Sure’.  The answer is valid, but because of the question, I’d most likely have to ask the more specific questions later.  Instead we were able to talk about specific areas of the project that needed further testing for boundary conditions and testing the unhappy path.

One exercise that I do occasionally is to go 24 hours and consciously make sure I don’t ask any general questions.   After I do this, I find that I continue to ask more specific questions without thinking about it.  Of course this leads to other issues when it comes to my kids. Rather than ask “Have you done all of your chores?” I’ll ask “Has the laundry been put away? Have the dishes been put away and the dishwasher loaded? Have you cleaned your room?”  One of my kids might answer yes to all the questions and bound off to their room.  When I follow up with “Why is the living room dirty?” the answer is usually “You didn’t ask me if the living room was clean…..”  Se la vie.

Failed IT Projects Cost Billions: Train wreck in slow motion

Regardless of whether you are developing a new application, website, or implementing a new software system, failures and setbacks occur.  It happens.  It's inevitable.  It costs.  Billions.  This article from the Globe & Mail (Canada) talks in depth about the scale of IT failures and some of the potential "whys" .

Let's lay some groundwork here:

The UK public sector alone spends circa 22.6-billion pounds each year on IT, and some reports suggest that 1.5 billion-pounds have been wasted on failed IT projects since 1997. A 2004 report from the UK Royal Academy of Engineers and the British Computer Society estimated that only 16 per cent of these projects succeed, and confirmed that billions of pounds each year are wasted on them — throughout the EU.

Indeed, statistics suggest that 50 per cent of all IT projects fail, while 40 per cent are late and/or over budget, and ultimately delivered with reduced functionality.

These various controversies have led to a major reform of how the Government in the UK and Ireland handles large scale IT projects, but the jury is definitely out, and public trust in elected officials has visibly eroded.

But lest we get smug here in North America, it is abundantly clear that such wanton waste is not just an EU concern. It is a global pandemic that needs urgent attention. And Canadians have plenty of home- spun examples to call upon.

In the US, the FBI recently disclosed that a post-911 IT project that has cost $170-million (U.S.) to date has been an abject failure, and that they will have to start again. Sen. Patrick Leahy of Vermont, the senior Democrat on the Senate Judiciary Committee, was quoted in Wired magazine as describing the whole fiasco as "a train wreck in slow motion."

Source: Globe & Mail: GlobeTechnology

You're not going to read any smug "it's never happened to me" lines here.  There are still a few projects I'm sure we all wish we had never started.  Several projects that, although they were eventually completed, were over-budget or somehow short of expectations.  So the question remains, why.

Doh! The worst all time software bugs.

I love this article by Wired on the all time worst software bugs.  Inspired by the recent Toyota Prius recall Simson Garfinkle goes through some of the worst.  Sadly many of them involve medical devices and people getting hurt or killed.

Besides shaking your head at some of the bugs (including the first "bug" ... which was a moth ...), think about the lessons in these bugs.  Many of them were caused by bad assumptions.  Software developers not getting into the heads of the users.  Others were sloppy work.  One was out right sabotage (I wouldn't call that a bug).

What's to learn here?  Never release?  Heck there are always bugs in code.  No, I think part of it is having good processes in place to check work.  The other part is to think like the worst user you've ever come across, do what they would do.  Maybe intentionally hit control key combinations that are strange, but might happen if someone has large fingers or isn't looking.

I remember a story of a senior programmer checking a junior's work.  The kid said that the program is solid and works great.  The senior guy smashed both hands down on the keyboard and hit lots of keys in the process.  The app crashed.  Big time.  The kid responded ... No one would ever do that!  The senior guy said ... Wanna bet?

Bugs aren't UI issues.  Bugs are things that shouldn't happen ... the user is following the correct steps and the wrong result comes up.  Maybe it was triggered by something else, but that's it.

So, what are the worst (best?) bugs you've seen?