Splitting stories into tasks – when, why and how (or not)

Before I write anything about this, I’d like to clarify what I mean by a task and a story.

A feature is something tangible that works and which we could potentially deliver, if it was enough to provide business benefit. Usually a bit of a screen or page, together with all the logic and validation associated with it, is a feature. A feature is the highest-level thing which a developer could work on without doing significant bits of analysis. It’s a part of an idea made at least concrete enough to imagine.

A story is a part of a feature on which we can get feedback from relevant stakeholders. For instance, we might code the UI, then the validation and messages, then an aspect or two of the behaviour behind the UI. Each of these would be a possible story. The only real reason for splitting features into stories is to get faster feedback and a better idea of progress.

A task is a part of a story which doesn’t allow us to get feedback from relevant stakeholders. If you can get feedback, it’s probably a story rather than a task, because it affects the UI in some way, or at least gives something that can be visibly verified and critiqued and which stakeholders care about. There are lots of UIs and lots of stakeholders and users, so “put logging in to help maintenance debug the situation where the elephant appears on the screen” might be a perfectly good story. Anything that’s just a part of a story is a task.

A task can’t really be tested either, even by a developer. You have no idea if a database has the right tables or data until you connect it to something. You have no idea if an interface to another system will work until it’s actually talking to that system. You might unit-test it, or run some queries, but it’s a level below the feedback and user testing available for features and stories. (There are higher levels of testing too, in which we can look for user capabilities and business outcomes, stakeholder goals, profit / loss, etc. – so you can’t really tell if *anything* works until you put it into production – but that’s a blog post for another day).

Why do some teams split stories into tasks?

A lot of Scrum teams particularly do this, because it’s traditionally taught as part of the Certified Scrum Master course. Hopefully good CSTs, and their CSMs, are teaching the benefits along with the practices.

It can lead to more accurate estimates. Splitting stories into tasks can help developers to think about the amount of work involved in a story, and find any pieces they missed.

It can help with collaboration. By splitting a story into tasks, developers can each take that task – usually a different horizontal slice – and work with minimal merge conflicts and just a bit of adjustment to get their piece working with other people’s. Splitting a story into tasks is useful for swarming, and a lot of swarming teams do this instinctively, even if they haven’t written the tasks down.

It can help senior developers mentor junior developers and verify that they’re taking a good approach towards a story. Some mistakes are worth avoiding.

They can be used as a measure of progress to someone tracking the team, like a PM or Scrum Master.

Why don’t other teams do this?

Some teams prefer to focus on delivering something on which they can get feedback, and find the tasks distracting.

There are also other ways of getting accurate estimates. Talking through scenarios can help with this. A lot of teams don’t use estimates anyway, preferring to stick to SLAs or their own instinctive understanding of how much work they can get done and whether they’re going to release on time. Anther purpose of estimation is usually so that the business stakeholders can have trust and confidence in the team, and there are different ways of getting the trust of stakeholders, too.

What bad things might happen if we split our stories into tasks?

Splitting stories into tasks might indeed distract from delivering something on which the team can get feedback. When a developer sees a list of tasks in front of him, he tends to work through those tasks methodically. He might not notice that, for instance, the team isn’t going to deliver *any* stories this week.

Using tasks to estimate team progress can also be misleading. If all the developers end up working on their own stories, the PM might see lots of tasks being done. If none of those stories are ready for the showcase, though, the team won’t be able to get feedback from their stakeholders – and might end up building the wrong things altogether! Also, the Pareto Principle suggests that 20% of the causes are responsible for 80% of the effects – or that the last 20% of the story might take 80% of the time. Often developers will start with the easy bits and leave the hard things until last.

People seeing the tasks can use them to micro-manage the team, asking who’s working on which task, or even assigning particular tasks ahead of time! But anyone with a manager or Scrum Master who does this has bigger problems than the task-splitting, I think.

Why do you absolutely hate people splitting tasks then putting hourly estimates on them?

First and foremost, this harks back to the old myth that time = work done. Even if developers are only held to be productive 50 or 60% of their “ideal” working day, the focus is still on the number of hours spent, rather than useful software being produced. It’s perfectly possible to spend hours on something that doesn’t work. A team which signs off all its tasks is subtly encouraged to say that they’re “done” without checking that the software they’re producing is useful.

What about the developer who plays with something else while turning over a problem in the back of his mind, then delivers an ingenious solution in 2 hours? Or the developer who wants to try out another way of solving the problem which might involve a steep learning curve, but which would benefit the project in the long run? By pinning these developers down to their hourly estimates, insisting on a certain timescale of productivity, we encourage them to tread the path they had in mind when they made the estimate, even if a different idea occurs to them at the time. Since human beings get a kick out of being right – suffering horribly from confirmation bias and the preference for validation – just the act of estimating the hours will pin them down subconsciously. They may not even think about the problem or have the new idea! Hourly estimates can stifle innovation, and the less wriggle room there is, the more innovation will be stifled.

Finally, it encourages micro-management. A project manager who sees a developer working on some tasks that should have taken 8 hours, but have taken all week, might wonder why that developer is taking so long. However, uncomfortable enquiries will only cause the developer to pad their estimates next time – and work expands to fill the time available, so the team will eventually slow down.

Should we do it or not?

If you think splitting stories into tasks might be helpful, try it. If it doesn’t help, stop. However, please resist the urge to put hourly estimates on them – or to ask that your team does so.

This entry was posted in feedback, scrum, stories. Bookmark the permalink.

12 Responses to Splitting stories into tasks – when, why and how (or not)

  1. Olaf Lewitz says:

    Great summary. Important to not forget all those little bits of command and control that tend to slip back into your process if you’re not aware… like those hours.
    Thank you!
    Olaf

  2. Ariadna Font says:

    Thanks for a great post! This comes at a perfect time for us ;-)
    Btw. I took your advise (at Beerhive in SLC) and am trying to get our macro team to organize around “streams”.

  3. unwesen says:

    “Also, the Pareto Principle suggests that 20% of the causes are responsible for 80% of the effects – or that the last 20% of the story might take 80% of the time.”
    The first part of that sentence sums up the Pareto Principle, the second part is … dangerous, and one possibly reason why developers tend to not take to the “story” term very well.

    The thing is, developers know very well how easy it is to present the illusion that something is done, when in reality it isn’t (some don’t). If you finish up a UI for a story, it looks as if the vast majority of a story is done, because all that’s tangible to anyone but the developers themselves is done. Those perceived last 20% of filling in the UI with functionality are quite often 80% of the work, though.

    For that reason, I drill into developers’ heads that the pareto principle as applied to software development is wrong (philosophically speaking it’s right, but it doesn’t help matters much to say that), and they should concentrate only on the time they actually take to finish something rather than look at the effects they’ve achieved to gauge progress. It’s not easy, but the perspective helps people reach more realistic estimates for their work.

    In other words, “time = work”, but as you say above, definitely not “time = work done” (or “time = progress” as I’d put it).

    I also drill into developers’ heads that “done” from an effects perspective only happens when your stakeholder can use it. I find it useful to introduce developers to the “story” term from this angle, because it’s a much more tangible approach. Otherwise I’ve found the reaction quite often to be that stories are extra administrative overhead that developers don’t like.

    • liz says:

      Hi Unwesen,

      I think I have a different definition of “story” to you. I would probably call anything the user can actually use a “feature”. I have quite a big focus on getting feedback due to doing risky stuff first, which is also why I bring up the Pareto principle. I frequently find that I discover things towards the end of a feedback loop, often when I’m expecting it to work and it doesn’t. Can you explain why you think “the last 20% of the story might take 80% of the time” is dangerous? I’m not talking about 80% of the effects here, but instead 80% of the estimates (so the other 20% turns out to be harder a lot of the time) – does this change your perspective at all?

  4. Bas Vodde says:

    Hi,

    Nice article. A useful addition could the the context in which teams do or do not generate tasks. In my experience, it depends on a lot on the type of product developed.

    One comment on hour estimates. I still promote adding hour estimates to tasks partly because I find the activity of estimating very useful for discovering differences in understanding of the tasks. So estimating tasks as a group tend to create much more clarity on the work, which is useful by itself. Also, many teams feel more confident that they can actually finish the stories selected in an iteration which increases focus.

    So, I still like hour estimates, though try to make very clear that it is unimportant whether it was accurate (and thus never track actual hour spend) but only that the sum gives additional information for the team to select stories in an iteration.

    Bas

  5. kristin says:

    How do you do sprint burndown charts in this scenario? Stories? Points everyday?

    Very curious. This is something we’ve been struggling with.

    Thanks!

    • liz says:

      Kristin, at the end of the day, the burndown is only there to give the developers feedback on how well they’re meeting their sprint commitments. Generally I find the teams have a good idea of whether they’ll make it or not anyway, and they’ll sign up to a realistic amount of work given half a chance. I’ve encouraged them to split up their stories more finely – but vertically – which also helps. You may find this useful: http://lizkeogh.com/2008/09/11/splitting-up-stories/

  6. Pingback: QuickLinks for August 2011 | (Agile) Testing

  7. Liz,

    I cannot see why stories and tasks should need the “feedback” criterion to recognize the difference between those concepts.

    I always thought that a story was something that a user and the system do, whereas a task is something that a developer does. In my view, a task is something that changes the system so that the user can run his/her story.

    So, stories and tasks are clearly separate because they happen in different minds: the users mind vs. the developers mind.

    How does that relate to your definition?

  8. liz says:

    Hi Matthias, as I understand it in Scrum, stories can be split up into tasks, each one of which is something which gets closer to enabling the stories. You’re completely correct that a task normally happens only in a technical mind, though there are some tasks which might be of interest to other techncial stakeholders with cross-cutting concerns (eg: security, architecture, logging).

    I’m encouraging people to do *as little as possible* to get feedback. For instance, you can create a GUI with hard-coded data behind it, and call that a story, because it lets you get feedback. Feedback isn’t just the criterion for difference, it’s the reason behind why we do Agile in the first place. If you can’t get feedback from a small change to the codebase I suggest that it’s a task, rather than a story, and should be treated accordingly.

  9. Pingback: September Links | Learning Agile and Lean

  10. Vaidy says:

    We use hours against tasks to time-box them. We encourage our programmers to externalize what they’re working on with others on the team, when they’re nearing the earlier estimated hours, but have not made proportional progress. This helps us to keep the stories/features/project more on track in terms of overall timeline.

    I do however see your point that this could stifle creativity in coming up with better solutions. I wonder whether is a middle path?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s