To break or not to break stories down into tasks …


When using Scrum we commonly have two backlogs, defined by the Scrum Guide as follows:

  • Product Backlog is an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product.
  • Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal.

This morning a colleague asked the question whether their team should breakdown their backlog into tasks, plan and assign what can / needs to be achieved in each sprint. It triggered this post, as it is a frequent question and deserves some attention.

Normally I would answer yes, yes and yes to the question above, however, this morning my answer was optionally, yes and optionally. Huh?

PS: MartinH, for the sake of supporting your health and blood pressure, I recommend you proceed to next post at this point.

emphasise context of this post

Reading our free Managing Agile OSS Projects with Microsoft VSO eBook and posts such as https://aka.ms/only15min you quickly realise that our ecosystem is challenging. Our teams are staffed by part-time volunteers, working around the globe and committing a daily average of 15 minutes bandwidth … that’s just over an hour per week!

Subsequently less is more, optimisation is key, and  adhering to frameworks such as Scrum and Scaled Agile Framework (SAFe) is downgraded viewed as guidelines, not prescriptive guidance.

a platter of dogfooding observations … anti-patterns?

Typically we have a portfolio backlog, representing ideas that will unblock, enable and make users happy, represented by the Epic work item type.

Each Epic has one or more Features on the product backlog, each of which is further broken down into Product Backlog Items (PBIs). Program Managers and Product Owners track project ideas using the Epic and Feature level Kanban board … visual and simple.

image

Our teams optionally break down the Product Backlog into Tasks, assign them to sprints, and use the Task Board to find work and track progress. Seemingly granular, detailed and time-consuming.

PhotoScan4

Three common anti-patterns I have observed with our part-time project teams using this granular approach, progress through their lifecycle:

  1. Teams spend less time breaking down PBIs into actionable tasks over time. The focus shifts from pedantic detail to getting the job done.
  2. Tasks are often orphaned in past sprints or parent PBIs that have been marked as done. Updating the tasks is either high-maintenance or they were forgotten (never used).
  3. Stakeholders spend waste valuable time grooming backlogs, orphaned tasks and often hear: “oh, those tasks … they were completed as part of changeset XYZ a long time ago” … unlinked Sad smile and forgotten Sad smile.

Others stop the breakdown or work items at PBI level and use the Kanban board to find work and track progress … seemingly visual and simple.

For example, looking at the following visual we notice that we may have a problem with too many bugs blocking the production chain, with reviewers and testers idling between the developers and the product owner’s final review … wasteful and frustrating.

image

Another anti-pattern that Anisha Pindoria, Rui Melo and I discussed at length this morning, is that projects and sprints always start with a spike of enthusiasm and passion.
image

Eventually the family>job>rangers reality settles in and we observe a flat cruise line of less activity. During the last week of the 3-week sprint, the call for status creates a spike, panic, and grovelling. What follows is a heroic spike of commitment and activity … and we ship!

We did not come to any conclusion other than “it’s human” and (at this point) have no antidote.

my 2’cents view

Encourage teams to self-organise and decide on the granularity that work needs to be broken down by. Turn the granularity dial to suit the team!

The heading  “my 2’cents view” encourages me to share by personal views:

  • With only an average of 15min/day bandwidth, the effort of managing work at task level is expensive and wasteful in the context of part-time, volunteer based teams. 
    • Keep an eye on orphaned tasks and question their value early in the project roadmap. The “oh, those tasks…” is a good indicator to turn down the granularity dial.
    • If a team member needs a granular list, suggest a personal board, or get them a box of sticky notes, or remind them that every Epic/Feature/PBI has a description field to accommodate as much detail as is needed. 
  • Sprints (in our case 3-weeks) are critical for alignment, inspection and adaption of overall progress, even when we do not associate work items with individual sprints. 
    • End-of-sprint reminders and call for status are a good wake-up call for many teams.
    • The usual pike of passionate activity at the start, flat-line in the middle and heroic spike of activity at the end is contained within a short sprint … levelling out overall.
      image
  • Scrums (in our case weekly 15min) are an invaluable heartbeat, an opportunity to synchronise, discuss and raise impediments.
    • No heart beat == Zombie … run!

IMPORTANT … I am NOT saying not to go granular to Task level or even further. Instead turn the granularity dial until the value to the team turns into waste, then start fine tuning. We would prefer the Rangers to invest 14 out of 15 minutes in sharing their passion, knowledge, experience and build value, and <1 minute to track and maintain visibility of the progress, issues and blockers that we, the Program Managers, can deal with.

thoughts?

We cannot wait to hear from you. Add a comment below or contact me on my blog.

Comments (4)

  1. Dylan Smith says:

    I find that everybody has a personal to-do list at a fairly granular level (even if it's only in their head).  Those that are good at time management usually write it down somewhere.  And we all should strive to be good at time management.  If we're writing it down somewhere anyway, why not TFS Tasks?  That's how I think of it at least.  I would think it would be especially important on a project that you only work sporadically, as it makes it that much more likely we'll forget things.

  2. Me says:

    My opinion below is more about traditional work environments and, I think, relates less well to the author's particular emphasized context of this post. Nevertheless, I offer my opinion in case someone with authority is thinking about making breakdown of work into tasks a requirement for his or her team.

    I consider the mandate to write down granular tasks as a form of micromanagement. It's a motivation, autonomy, and inspiration killer. User stories are already supposed to be granular enough to fit in a sprint. A loose analogy: if a contractor is working on your house, do you ask him to break down his workday tasks in sub-hour or hour increments? Of course you don't. But why not? Because, frankly, you don't care and the contractor definitely doesn't want to spend time doing that. You're only interested in the story completion or larger milestones and the quality of the output: is the plumbing ready in the bathroom? Can the inspector come to check such and such? Is everything done well?

    There is tedium and the increased possibility of rework when breaking things down too far. You'll end up spending a lot of time writing down all the steps for what you're about to do in the next two to three weeks when you could just spend that time doing the thing you're about to do. Plus, it removes some of the fun of investigation, exploration, and tinkering as you figure out the best solution for the work at hand. If you are breaking things down into tasks up front, you're going to pick the known path as a default just so that you can get through writing out the sequential tasks. That's not good. You want some freedom and creativity to be allowed, as better solutions are often found that way.

    At the very least, leave it up to the team. Ideally, I would think an individual can decide whether to keep a personal task list should the individual need it.

    As far as the initial enthusiasm spike in a sprint followed by the heroic effort at the end, I think part of this is somewhat inherent to Scrum. I think Scrum *tends* to look like mini waterfalls. I think Lean Kanban tends to be more level as it is more about continual flow of work.

    @Dylan Smith: I'm good at time management and I don't write down task breakdowns unless the thing I am doing is too complex to keep in my head. So, knowing when to utilize a tool is important. Knowing the individual is also important. Your suggestion of writing down tasks if you are only working sporadically on something (the context of this post) is a potentially good idea, though.

  3. David Parvin says:

    I think the tasks are useful for two purposes:

    1.  Breaking down a large complicated PBI into parts that can be given out to multiple people to complete

    2. As a way of remembering all the different parts if the thing you are doing and making sure you finished them all.

    They are a means of communicating to the team that this is all the parts of this item that needs done and who is working on what and how much time will need to be devoted to finishing each piece.  If you can do all that without putting in tasks then you have no need for them.

  4. Roger says:

    @Dylan

    TFS tasks are too painful to use. We use Trello and its so much simpler and faster for our daily to do lists. In TFS we keep everything at the Feature/Epic level.

Skip to main content