Sprint planning with work breakdown and time estimation
Back in 2009, when I started my “Agile life” with a course of Agile estimation and planning, I was taught how to do high level estimates by using complexity, to define work size and calculate team velocity. I also learned that on planning sessions we should break the work into tasks and estimate them in time. With this low level estimate, the work should be added to the sprint until the Team capacity is fulfilled at a level accepted by the Team.
Maybe conditioned by the tools that I used, I see the allocated work and the capacity managed in an individual level: each one has its on availability to the Sprint and the estimated and allocated tasks fulfil that capacity, so each person decides if it’s comfortable with is allocation for that time interval.
All this makes sense in my head and, to keep the focus on the Team and the Team work, I always tried to guarantee that the estimates were made not individually but by the Team (at least with more opinions on the Team) and the allocation was defined by each individual that takes the task, and not by someone that tells who should do what.
But, over time, this process started to raise some doubts regarding its Agility. To begin with, it’s a predefined process that the team should do and needs some amount of time to do it. On the Agile manifesto there’s no processes — it emphasis the importance of people and interactions over processes and tools — and the Scrum guide does not have nothing explicit for this. So, keeping Agility in mind, we can/should do this or not?
Being Agile is to be able do deliver more and better value. Does this process have value? Does it bring value to the product?
To better understand this, let’s break the process in two parts: the high level estimate on refinement sessions and the low level estimates on planning sessions.
Refinement with high level estimates
When a team refines the backlog, the most important is to understand what is wanted in each backlog item. The need to estimate is a way to make everyone understand what is involved on that product increment. If I have to define how complex is a functionality, I have to understand it first.
Two examples on how this process can be helpful:
- If the teams give different values to define the size of a backlog item, it shows that there’s various levels of understanding on that subject and the team should discuss to build the common view, levelling the knowledge and diminishing the uncertainties.
- If the increment is too big or too complex, then the team should break that item in smaller ones, keeping in mind that each new backlog item should be Independent, Negotiable , Valuable, Estimable, Small and Testable (the known INVEST acronym created by Mike Cohn).
For this phase, I find great consensus on the value of this process, as a way for having a good product backlog with a quite accurate mid term predictability for new features implementation, using the team’s Velocity to evaluate what can be done on the following sprints. The Team can use Story Points, T-shirt sizes or other kind of values to define backlog items size/complexity. Some Teams are more comfortable on using an Effort value to define a high level estimate of time for that work. Others just break the work so each Backlog Item can have the same size (#NoEstimates). The importance of this refinement process resides on getting a clear understanding of whats need to be done and, by taking advantage of that process, to have a size of each wanted product increment for future calculation of team velocity.
Still on the refinement sessions, could we do a more detailed estimation of the work needed? We could, but when we are refining the backlog items we don’t know when the work will be done, nor what will be the product state when the item is to be done. That increment may even loose priority and/or feasibility, and may never be done. So, if we do a more detailed evaluation of the work needed on an early phase, it can just be a waste of time.
Planning with low level estimates
On the planning sessions, the team should define what the team should deliver on that sprint, following the priority order on the backlog. The Scrum guide also refers that the team should define “How will the work needed to deliver the Increment be achieved”.
There are several techniques for the team to use to define the amount of work that the Team believes it can deliver on the Sprint. Next, some examples.
- A Team decision just by its own experience or gut feeling
For a mature/experienced team and a known product built on a known technology, I think this can work really well. But, come on, when does this really happens?! If this is your team, congratulations! And please, don’t loose time on planning details, go on and do your stuff!
- Use of the high level work estimation and the Team velocity
We can use the high level estimate to define the amount of work to be addressed on the Sprint. We measure the team velocity — we sum the sizes of delivered Stories on each sprint and calculate the average value for the last sprints, no rocket science — and use that value to define the amount of work to put on the next sprint.
But I have a thing or two about using the teams velocity, with complexity size, to help define the Team commitment. It seems like we are aiming to maintain the velocity instead of using it to measure possible improvements or regressions due to implemented changes on the self continuous improvement process. Another point is that, depending on who does the task, the amount of time needed to do a Story should be different but the complexity should be the same. But maybe it’s just me…
- Just count the amount of Stories that have more or less the same size
This is my vision of #NoEstimates, to work on the backlog items so we can have possible increments with similar size. Then, the estimation is similar to the use of Velocity but we just need to count the amount of items that the team believes it can do.
- Estimate the work and manage the capacity, with work breakdown, assignment and estimation
On this, I see three aspects to be considered:
1. Work breakdown
This breakdown can be seen as detailed definition of the tasks needed to accomplish the product increment defined in each backlog item. Is it really needed? It’s important? For whom? Some people may say that it helps to structure the work that has to be done. Other may say that don’t need it and that is just a waste of time, to define the tasks and to have to move that small amount of work over the Team board. This may even look like a kind of micromanagement, so someone can control what you are doing.
Despite the individual opinions regarding its own work organisation, I see the value of allowing to visually follow the work evolution, by regularly see tasks being closed towards the backlog item conclusion. Regarding the micromanagement possibility, I prefer to think that this can help to give visibility and transparency on the product evolution.
2. Work allocation
An Agile way of work should be flexible and focused on what is considered more important to the product or, at the Sprint level, to achieve its goal. For that, the work should be done by the predefined priority order and by the person that is available to do it (and can do it).
But our teams, at least the ones that I’ve worked with, normally have specialists of some kind of work or technology and we can have more productivity when one do some kind of tasks. The Agile teams should be cross functional but we always have specialists on different areas needed to build the product. To be cross functional means that the Team have someone that can do the tasks needed (or, at least, most of them) and not that everyone on the Team can do every tasks. To have a Team that everyone can do every kind of task sounds really cool but, depending on the product, can be very unrealistic.
So, when planning a Sprint, should the team do a first exercise of allocating the tasks, to address the needed work to the available team? Or just let the team do the work that is needed by the one that can do it when that time to do it arrives? On other words, should we do a previous allocation of the work have the commitment be set by the sum of individual commitments? Or just have a vision of the work and have a Team commitment on the Sprint Backlog definition?
When addressing this individual and Team commitment issue, we should also remember that the Team capacity may vary from Sprint to Sprint, as people tend to have vacations, trainings and other needs that make them out of the office. And this normally happens individually, not the all team. If the team have specialties, the capacity to do some kind of work will vary. If the individual contribution may affect the kind of tasks that a team can deliver and it’s important to have a (good) predictability of what the team may deliver in the sprint, the work allocation may be relevant.
3. Work estimates
The relevance of doing a more detailed estimation of the work to be done may reside on two levels:
a) The need of the Individual to plan his own work on the sprint
When the teams plan a Sprint and do a commitment to the work that believes it can deliver during that period, some persons can be more comfortable if they break the work to visualise its own tasks and give a time estimate to compare to its own capacity.
This can be extrapolated to the whole team, by doing this with all team elements. The sum of each one work will be the team initial commitment. In my own opinion, this does not means the plan is fixed and nothing can change during the Sprint, this should be the Teams commitment and everyone should help accomplish it. This means that, during the sprint, the allocation may change in order to deliver what is more important or to accomplish the Sprint goal. Remember that no plan is bulletproof and unplanned things tend to happen — it is important to always have Murphy’s law in mind:
“Anything that can go wrong will go wrong”.
b) The need of the Product Owner and Stakeholders to have a predictability of what the team can deliver on that Sprint
This is only relevant if the teams commitment on a sprint is important. What happens if the team misses the commitment? What happens if a defined goal is not accomplished?
Normally, the Product Owner and other Stakeholders need to know if the Sprint goal will be accomplished at the end of the sprint. But this may not have the same relevance for every product. If, in one product, it’s ok that the team may deliver the most important backlog items that the team can do, with no previous commitment, a detailed plan is not necessary. Instead, the commitment is in the willingness and availability to do the best that each one can. Risky? Maybe.
Can this commitment be a way to focus the Team on what can/should be done on that period? By doing this as a strategy to work on the team, are we doing babysitting work? If so, should we do it? I think we do, as a technic to improve and, when applying it, evaluate if it works or not.
If the commitment is very relevant, can the team be defensive on the estimates to define what can be delivered on the Sprint and, by doing that, delivering less that what could be done? Of course, but this can also may be a good point to do the estimation with all the team, making everyone do a small push on others to do more realistic estimates and trying to deliver as much as possible.
Following another acronym, the Sprint goal should be SMART (Specific, Measurable, Achievable, Relevant, Time-bound). To better respond to a goal, shouldn’t be Relevant to do a more detailed plan to better evaluate if it is Achievable in the Time-bound? But again, to be Agile and build a good product, is this Relevant?
So, what do you think? Sprint planning with work breakdown and time estimation, is it worth it? Or just a waste of time?