Menu

Blog: Estimating Product BacklogThe current version of the Scrum Guide (2019) says “The Sprint Backlog is a plan with enough detail that changes in progress can be understood in the Daily Scrum”.

It also states that the “work may be of varying size, or estimated effort. However, enough work is planned during Sprint Planning for the Development Team to forecast what it believes it can do in the upcoming Sprint. Work planned for the first days of the Sprint by the Development Team is decomposed by the end of this meeting, often to units of one day or less” and then during the Sprint “the Development Team or team members often meet immediately after the Daily Scrum for detailed discussions, or to adapt, or replan, the rest of the Sprint’s work”.

In my experience the key thing is that the team have very small work items in the Sprint of no more than one or two days of effort each. I’ve also seen first-hand that the teams who self organise at this level of granularity tend to be more successful than teams that do not (for a number of reasons – such as understanding the work, commitment, transparency etc.). This means that the teams need to do some level of estimating (do we think the work item is probably less than a day or two of effort), but they need not, and should not, spend a long time doing it.

Splitting the Product Backlog

Some teams are able to split their Product Backlog Items (PBIs) to this level or close to it – in which case they may not need to identify and plan tasks. I would consider (and only consider – other socio-political factors may be at play) recommending such teams to experiment with planning tasks within PBIs only if their current practice isn’t working for them and they are frequently failing to achieve their Sprint Goal.

Other teams (despite all the coaching in the world!) are not able to split their PBIs so small – or can do so only by resorting to PBIs that are not true ‘vertical slice’ User Stories (typically those teams working on very large and / or legacy systems). For such teams the only way to get down to very small 1-2 day work items is for them to identify and plan tasks. In such cases this is what I will usually recommend (again, unless other factors are at play).

Back to the Scrum Guide, and interestingly it is imprecise on this point. The Scrum Guide does not say explicitly whether the work in the Sprint should take the form of PBIs or tasks. However, it does say that the Sprint Backlog is “the Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal”. It seems to follow that if all you have is a list of “the Product Backlog items selected for the Sprint” without any additional “plan” then strictly speaking you don’t have a Sprint Backlog … so you aren’t really doing Scrum, if that bothers you!