Estimating work serve a number of purposes on a Scrum team.
- Estimates allow Product Owner to maximize value delivery and prioritize ideas and initiatives based on cost of development (story points or tshirt sizing) and anticipated value.
- Estimation should be done by the team that will be doing the work, the exercise of estimating as a team help by surfacing differences in work approaches between team members and for them to align and agree on how to get the work done.
How do we estimate with limited knowledge?
Often at the start, teams are less familiar with the work required especially if it is something they have never done before, where third parties are involved, where they need to do extensive research for each work item. When estimating they may choose to use relative estimates such as Fibonacci numbers or t-shirt sizes.
This technique removes the need to provide accuracy but gives us an idea how how big the backlog is.
The goal for estimation during early days is to establish a common language, not exactly for accuracy of estimation. That comes over time with trends and real data on the team’s throughput and velocity.
Estimating large backlog items
When a backlog item is too large, the team can break it down further by asking the Product Owner questions and split the large story into smaller stories using acceptance criteria.
The team can also differ estimation when they don’t know enough and ask to do a SPIKE to learn more about the work that’s required before estimating. The team then revisit the story to be estimated.
Do we have to estimate the entire backlog?
It’s more important to estimate the items on top of the backlog since the Product Owner requires this information to prioritize the backlog to help the team focus on delivering the highest business value work.
What teams tend to do is to estimate the entire backlog using either T-shirt Size or Story Points, the bottom of the backlog are often full of very large EPICs and stories, the top of the backlog are often more refined and estimated in story points.
How are story points estimated?
As we get closer to iteration or Sprint planning, the team will need to do more detailed estimations. This is often done before iteration planning at a backlog grooming session. New teams meet daily to groom the backlog to get the backlog to a well-defined state.
During backlog grooming, the Product Owner shares the work to be done with the team and reminds them the intent and how she or he wants it to be demoed once the work has been completed. For non-tangible work, this could be a show and tell, a process map walk-through, feedback from users and customers, list of decisions made and shared.
Estimates are often based on a number of factors, including:
- Team’s skills and knowledge in the domain
- Who’s doing the work
- The complexity of the work
- The effort required to get the work done
- The time required to do the work
- The time required to validate and demonstrate the solution with customers
- Learning required
- Risk and impact of the risks
- Amount of assumptions being made at the time of estimation
Remember: story points are estimated by the team that’s doing the work, not by an individual team member, a technical lead or a team lead, this is a step towards cultivating a culture of teamwork and the mindset of working as a team towards a common goal.
For a large group of workstream or teams working together, it is useful to commonly agree on the definition of ready, the definition of done and what units and method they will use for estimation. It helps to use historical work as a reference, if this is not available then it might be worthwhile running a number of iterations for the team to figure out what a 5 point story looks like, and use that for reference when estimating.
There are two types of estimation techniques:
1-Relative estimation
2-Precision estimation
Most estimates are relative. Teams start estimating by finding something they have completed in the past, if they have no history of working together, then it is useful to run a number of iterations as a team to get a sense of the team’s velocity and throughput.
User Story points are often used for relative estimation.
Estimating in hours and precision estimation is often not done until daily or iteration/sprint planning. Teams may choose to estimate tasks within stories at iteration planning to give each other an indication of where they are at with a task. Precision estimation is not done earlier because without having gone through release planning, iteration planning and having done some work already to learn about the work, precision estimation is likely to be wrong. Also, agile teaches us to plan often and do only enough planning for the next few iterations and release, so we can start work, and validate that we are heading in the right direction.
Good stories are independent, Negotiable, Valuable, Estimable, Small and Testable!
The INVEST principle helps us remember how to write good user stories to succeed with Agile. What does this have to do with estimation? Well, good stories are estimable!
Independent
Independent stories are work that can be done by the team without needing input or expertise from external teams. The reason scrum teams are cross-functional and multi-disciplinary is so that the team can be self-reliant and self-sufficient enough to deliver the work.
Negotiable
Is the scope of the story negotiable? The acceptance criteria is used to define the scope of a story, this is determined by Product Owners outlining what must be in place for the work to be accepted.
The story is not a contractual agreement but a reminder for the team and Product Owner to keep on having conversations about the work that is to be done. The team may find out that one of the acceptance criteria is not feasible and offer the Product Owner an alternative or the Product Owner may choose to swap out a story in the iteration with something more urgent, the scope of the story is negotiable.
Some teams will approach the work and realized the scope of it is too big, they will then negotiate with the product owner to split the story and add the second half of the story to a future iteration.
Valuable
Generally, a story must contain some business benefit and outcome, the activities within the story can be worked on by different people independently but they are all working towards the same value/outcome.
Estimable
The team should be able to estimate the work using either t-shirt sizing or story points, if it is not estimable, the Product Owner should seek to clarify what the ask is and how successful completion of the work can be demonstrated by the team.
Small
Must be small enough to be meaningful when visualize. Generally the smaller you can split the story, the less waste you’ll produce.
As a rule of thumb:
- EPICs are collections of large stories and can take Weeks and Months.
- Stories can be worked on multiple team members at once with multiple concurrent activities, they can take days to complete.
- Tasks and activities are completed daily and can be visualized on the Kanban board and discussed at the daily stand up.
Testable
The story should contain clear testable acceptance criteria on how exactly the work will be verified and tested. If the story is vague, it is difficult for the team to know how success is measured. The product owner must be very clear on what she’ll do to test the work for acceptance. For example “I want to see feedback from interviews with at least 10 users.” “Demonstrate to me the functionality to open a new account using a prototype software.”
Estimating intangible work
Before asking the team to estimate any work, the Product Owner must be able to clearly articulate:
– what is the intended outcome?
– what is the purpose and scope of this work?
– what value or benefit does it provide, for whom?
– who are the stakeholders? users?
– why is this important to do, why is it important to do now? Any known risks, issues, constraints.
– what would good look like?
The above questions help the team determine what is in and out of scope and can add to the acceptance criteria which frames the story, and helps with the estimation exercise.
Techniques for estimating intangible work:
1. Time-boxed the work – sometimes stakeholders don’t know what to ask for until they see what they want, it is better to do a small amount of work to validate ideas and get feedback on the solutions before spending too long down the wrong path.
When time-boxing, time is the constraint, it forces the team to focus on identifying and figuring out the most critical part of the work. In traditional project management, it’s important to find the critical path, what is the critical path in order for the process to be usable. This may be minimal? But the idea is not to stop there, but iterate to add more value.
One team I worked with, they broke down all the work into equal size, so they don’t have to worry about estimating but focus more on understanding the work and figuring out whether they can fit it into an iteration. This team has this luxury because they had worked together for sometime, they know how much their bucket holds.
2. T-Shirt Sizing – any estimate without sufficient information is likely to be off. Using T-shirt sizes help the team to not overthink. T-shirt sizes are xxs, xs, s, m, l, xl, xxl, xxxl.
3. Fibonacci numbers – these are the most scalable and flexible in my opinion. Since teams can work with much larger EPICs using the planning poker cards. At the start you may end up with many 50 points, 100 points stories, but once your product backlog is sized. You can then take the top item in the backlog and refine them with more details and allow the team to update their estimates.
Important note:
Note that story points and t-shirt size estimates do not cross team borders. They are like the currencies a Product Owner can use within the team and program. If a Product Owner of a multi-team program want to see overall progress, they should try to agree on reference stories, how to estimate.
No one should ever take the estimate from one team and give it to another team to estimate for comparison.
Estimation for predictability
To get to predictability, stable teams are important. If this is not possible you are better off measuring throughput and lead time, and figuring out how to improve flow in your process to get work done.
If you do have the luxury of dedicated, permanent teams, then you have access to meaningful velocity, throughput and lead time.
