Focus on Right-Sized work
In Agile, we estimate the size of a piece of work separately from the duration and cost. We start with sizing and let that inform the other two.
It is therefore important we apply a level of rigour and discipline to ensuring our sizing is as accurate as we can make it. However, we also have to assess the appropriate level of rigour and discipline that needs to be applied. Too much planning will be waste, too little will mean inaccurate sizing of an issue which will lead to poor estimates of the duration and cost associated with completing it.
In a Nutshell
When sizing a piece of work we are trying to assess how ‘big’ the work is, how complex it is, and how many parts make up the whole.
Once we have done this we can consider the velocity at which the team is able to sustain the work. This will be the number of issues (of a certain size and complexity) that they are able to sustainably deliver in a particular timeframe.
To do this accurately takes time, effort and resources. Therefore, we need to consider how accurate our sizing needs to be. For example, would you put the same amount of effort into sizing issues that are in the ‘Future’ column of your roadmap compared to those that are in the columns of ‘Now’ or ‘Next’? Probably not – what we would need to consider is the appropriate level of accuracy needed and at what point the amount of effort we are putting in to right-sizing starts suffering from the law of diminishing returns.
Issues that are closest to us require particular levels of accuracy. Generally, the smaller and more granular something is, the more likely we are to be able to accurately assess its size. Therefore rigour and discipline is required to reduce the amount of complexity surrounding the issue and the number of dependencies involved.
In order to increase our confidence in the size we have assigned an issue, we need to ensure we have considered the opinion of our team (the people who will be doing the work) and people with experience of the issue under scrutiny. We can also compare the size of this issue against similar past issues.
Related Practices
We review the flow of work through our system, paying attention to the overall rate of flow and to bottlenecks as work flows through our process. Where bottlenecks are identified we seek to understand the root causes of each bottleneck. With this understanding we relieve the constraints by experimenting with changes to our process. Where we see examples of accelerated flow, we look for practices facilitating this acceleration. We experiment to find ways to incorporate these practices into our process.
Product Backlog Refinement is a Scrum activity that is performed on the Product Backlog. The scrum guide defines Product Backlog Refinement as the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.
Most commonly, agile teams use relative estimation to size the work they need to do - that is they estimate the size of a backlog item relative to other backlog items. Relative estimation is based on having a sufficient understanding of a backlog item so that its scale, complexity, risk and many other factors can be assessed against those of similar, related or recently completed backlog items.
Sprint Planning is a Scrum event that is held before the start of the sprint to establish the scope and priorities of the coming sprint. Its purpose is for the whole team to establish an agreed sprint goal based on the Product Owner’s view of the value that can be created for the customer. To establish a scope of backlog items that can be got to done. For each backlog item the team decides how done will be achieved.
The Product Backlog is the vehicle by which needs are turned into requirements and requirements are turned into operational features in our product. It is a prioritised list of the work that the team currently intends to deliver in the next period of time. The less imminent a feature is, the less well it will be defined.