Burndown User Stories, Rather Than Tasks

Burndown Stories Rather Than TasksI was very interested to read this blog post from Ron Jeffries about burning down user stories rather than tasks. Excuse the pun, but this is a hot topic for me at the moment :-)

If it’s possible to avoid the time spent in Sprint Planning, breaking user stories into tasks and estimating them in hours, this would reduce the overhead of planning iterations in too much detail. This is something I am sure any development team would probably welcome.

Estimating only in points also allows a team to realise the full benefits of Velocity, which causes a team’s estimating to be self-correcting. Otherwise there’s a tendency for people to try to convert points into hours and reconcile them with the time available, which in itself can cause some problems (see here for examples).

Having said that, this would only really work if the user stories are small, e.g. 1 or 2 days. Otherwise, longer stories would tend to complete towards the end of the Sprint, meaning the burndown chart would not provide early feedback and visibility of progress throughout the Sprint. Personally I find the burndown chart an extremely valuable and powerful tool, so I think this is very important.

One of the comments on Ron’s post suggests that a team must be multi-skilled – all capable of working on everything – for this to really work. I don’t really believe that’s the case. If the user story is small, I don’t see that it would really need to be broken down for a team to collaborate and complete it. Say you have a designer, front-end developer, back-end developer and tester on the team. I’m sure they can figure out how to divide the work to complete the story based on their skills, without necessarily going through the process of breaking down every story in the Sprint Planning meeting.

I do, on the other hand, believe there is real value in the Sprint Planning meeting and completing much of this meeting as a team. But I think the most value is in the first part of Sprint Planning – understanding the user stories and clarifying requirements.

I’ve heard and read various different views on this. I’d love to hear your comments on it?


Photo by ViaMoi

6 Responses to “Burndown User Stories, Rather Than Tasks”

  1. Mike Cottmeyer says:

    Working for VersionOne, a tool that supports breaking down user stories into tasks, I often ride the fence on this issue.

    My ideal situation is one where the team can plan their work, commit to the iteration, and show a reasonable burndown within the sprint… all without doing task breakdown.

    As an Agile Project Manager, what I really care about is throughput iteration over iteration.

    Task burndown can give me a great leading indicator within the iteration, but ultimately it is not necessary if the team is good at making and meeting commitments.

    If a team is struggling to understand what is required to deliver the user story, needs more discussion about the nature of the work, have tasks that need to be completed my more than one individual – breaking user stories down into tasks (and subsequently burning down those tasks) can be helpful.

    Either way, I tend to look at project velocity as a means for the organization to understand how the team is making progress. It is an external metric.

    The iteration/task burndown should only be used by self-organizing teams to manage their commitments. It is for the team, so ultimately the team should decide.

    My $0.02.

    BTW – You seem to be posting more frequently, nice to have you back… keep it up!

  2. Kelly Waters says:

    Thanks Mike, very interesting. This definitely seems to be a point that people have very different views on. I think I agree with your comments and that it’s somewhat dependent on the maturity of the team.


  3. Derek Mahlitz says:

    Maturity of the team is an important consideration. My team has been sprinting for 7 months and I don’t think we’re ready for no task burn down. Although this time next year I definitely believe they will. Good Article.

  4. Slawomir Ginter says:

    There are 2 reasons why I believe the team should divide stories to subtasks during the planning:
    - story points are an estimated measure of relative story sizes, this estimate tends to change during closer inspection,
    - the process of dividing itself provokes lower-level discussion among team members, the tasks are better understood by the team and often this is the moment when most of the design is agreed upon.

    From my experience, it is much easier to make the right commitment when the stories are divided. The iteration also seems to go smoother due to better understanding of all stories.

  5. Anonymous says:

    I often wonder how to shorten IPMs. The teams I work with are often hungry to get started and start seeing how the stories play out in the iteration. I asked my current team and they suggested that talking about the tasks was useful. Further they suggested that the tasks estimates are not really useful because pairs reconsider the tasks when they begin a story. The consensus is then given small stories, a well gelled team, and pair rotation often this would be worth trying.

  6. jmckenna says:

    A definition I find useful: Stories are what teams commit to. Tasks are what individuals commit to. The comment about team maturity is spot on. Immature teams tend to not understand all the work that is really required to complete a story. Tasking not only provides raw data for a task burndown which is useful for the team (story burndowns are not useful unless there are a lot of stories, sort of like tasks!) but helps the team learn what the work really is and to account for all of it. Teams notice tasking patterns for stories and can task quite quickly. If they can not then they do not understand the work or their architecture or both.

Leave a Reply

What is 4 + 6 ?
Please leave these two fields as-is:
Please do this simple sum so I know you are human:)

There are 101 ways to approach anything.
To find the best way, sometimes you need expert help

What People Say

“Kelly revolutionised the way our digital department operated. A true advocate of agile principles, he quickly improved internal communication within our teams and our internal clients by aligning our business and creating a much enhanced sense of transparency in the decisions the business was making. Kelly also introduced a higher sense of empowerment to the development teams...”


“Kelly’s a leading program director with the ability to take charge from day one and keep strong momentum at both a program and project level driving prioritisation, resourcing and budgeting agendas. Kelly operates with an easy-going style and possesses a strong facilitation skill set. From my 5 months experience working with Kelly, I would recommend Kelly to program manage large scale, complex, cross company change programs both from a business and IT perspective.”


“Kelly is an extremely talented and visionary leader. As such he manages to inspire all around him to achieve their best. He is passionate about agile and has a wealth of experience to bring to bear in this area. If you're 'lucky' he might even tell you all about his agile blog. Above all this, Kelly is great fun to work with. He is always relaxed and never gets stressed - and trust me, he had plenty of opportunity here! If you get the chance to work with Kelly, don't pass it up.”


“Kelly is an Agile heavy-weight. He came in to assess my multi-million $ Agile development program which wasn’t delivering the right throughput. He interviewed most of the team and made some key recommendations that, when implemented, showed immediate results. I couldn’t ask for more than that except he’s a really nice guy as well.”


“Kelly and I worked together on a very large project trying to secure a new Insurer client. Kelly had fantastic commercial awareness as well as his technical expertise. Without him I would never had secured this client so I owe a lot to him. He is also a really great guy!”


“Kelly came to the department and has really made a huge impact on how the department communicates, collaborates and generally gets things done. We were already developing in an agile way, but Kelly has brought us even more into alignment with agile and scrum best practices, being eager to share information and willing to work with us to change our processes rather than dictate how things must be done. He is highly knowledgable about agile development (as his active blog proves) but his blog won't show what a friendly and knowledgeable guy he is. I highly recommend Kelly to anyone looking for a CTO or a seminar on agile/scrum practices - you won't be disappointed!”


“Kelly was a great colleague to work with - highly competent, trustworthy and generally a nice bloke.”


“Kelly was engaged as a Program Director on a complex business and technology transformation program for Suncorp Commercial Insurance. Kelly drew on his key capabilities and depth of experience to bring together disparate parties in a harmonised way, ensuring the initiate and concept phases of the program were understood and well formulated. Excellent outcome in a very short time frame. ”


“I worked with Kelly on many projects at IPC and I was always impressed with his approach to all of them, always ensuring the most commercially viable route was taken. He is great at managing relationships and it was always a pleasure working with him.”


“I worked with Kelly whilst at Thoughtworks and found him to be a most inspiring individual, his common-sense approach coupled with a deep understanding of Agile and business makes him an invaluable asset to any organisation. I can't recommend Kelly enough.”


“Kelly was a brilliant CTO and a great support to me in the time we worked together. I owe Kelly a great deal in terms of direction and how to get things done under sometimes difficult circumstances. Thanks Kelly.”