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.

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.

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 and forgotten .

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.

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.

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.
    
• 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.