Asking software product teams to be accurate using pure time estimates is difficult. It’s burdensome and generally not accurate enough to enable meaningful decisions. Even with agile product development, too many uncertainties exist for time estimates to be precise. Founded on empirical process controls, agility implies that learning comes from testing, making time estimating even more difficult. Add to that the agile principles and values of welcoming change, even late in development, and adapting over following a plan, and it becomes clear that asking a team to provide exact time estimates for a project plan is wasteful, useless, and frustrating. The better alternative is story point estimating.
What is story point estimating?
Scrum teams often use story point estimating, which is simple, fast, accurate, and purposely imprecise. Typically, estimate story points use Fibonacci numbers. This causes estimates to fit into clear, increasing buckets of effort (1, 2, 3, 5, 8, etc.), as relative estimates to other work in the product backlog.
For example, if a user story has an estimate of 5, the team feels it requires more effort than those given 3 points but less effort than those with 8 points. With agile estimating, the team values accuracy over precision. This means they can be accurate in placing requirements in buckets of 3, 5, 8, etc., rather than telling you how many hours each requirement will take.
Use story point estimating after you agree on the definition of Done
The team includes all the effort in its estimates to meet the user story’s acceptance criteria and reach their agreed-to definition of done. Teams should not perform story point size estimating until the team agrees on its definition of done.
When estimating, they consider the effort to elaborate, design, develop, test, automate, document, train, secure, support, and promote code to the various environments. They incorporate everything they can think of to create a potentially shippable product increment as they consider their estimate vote.
Product owners and dev teams use estimates
The product owner uses the estimates to prioritize work, generally placing low estimate stories with high value earlier in the product backlog. The development team uses the estimates to measure velocity history (how many story points per sprint they have been able to deliver in recent sprints), which helps the entire team forecast product releases using actual empirical data. It also enables the development team to better forecast how much to pull from the product backlog into the sprint. This leads to a fairer system for the team and tends to be more accurate for forecasting the achievement of business goals.
More importantly, however, those doing the work provide the estimates. For this reason, the people on the team with design and quality assurance (QA) skills are essential to the team’s estimates.
Why is design part of story point estimating?
It’s unlikely a customer will be happy with a feature that has only been designed. Likewise, customers generally regret purchasing something with a poor design. The customer wants to use a fully-functioning, well-designed feature that makes their lives easier. Product design is an integral aspect of making something “potentially shippable.”
Including design in the team’s definition of Done and story point estimating encourages the design to be as close to the development as possible. This reduces the chance of having a design that’s unusable and keeps the design up to date with the team’s understanding of customer needs and behaviors. It helps everyone participating in the estimating activity to consider product design along with the other definition of Done items.
Why is QA part of story point estimating?
A design without working, tested functionality (or the supporting backend) is unusable. Unusable completed product increments are an example of work in progress. Work in progress has absolutely no value to a customer. It’s like having a new, beautifully designed car with one tire and no engine, kind of hard to sell half-built, unusable products even if the design is remarkable.
Similarly, QA and testing are part of the team’s definition of Done. They are critical skills required for product development. The entire team, regardless of testing ability, considers testing as they estimate. Simply put, QA is part of the story. It doesn’t help for a team to say a story is done if they don’t have a reasonable guarantee of quality or that it will actually work.
For example, a developer may look at a requirement and consider the simplicity of the development effort. The peer team members, with testing or test automation skills, may reflect the same need and consider the complexity of the required testing.
Both team members benefit from each other’s perspective. They can reach the right balance when they agree on the estimate. When the scrum team receives the work, they will have a better view of how to accomplish it, respecting their teammate’s helpful perspective.
Estimating creates opportunity
Agile practices encourage everyone who will do the work to estimate it. Estimating as a team creates the opportunity for great conversations, which is the most important reason for doing it as a team. These conversations are precisely the interactions expected when you consider user stories to be placeholders for future discussions.
Estimates reflect all the skills necessary to create a working product increment, even design and QA. Including design and QA keeps the focus on delivering potentially shippable product increments to please customers, instead of just being “dev done” or “my piece is done.” As principle 5 from the Agile Manifesto suggests, “Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.”
Remember, estimates, by definition, have no guarantees of being correct. Our advice is to place more focus on building products that will “wow” your customer rather than your ability to improve your estimates. Use empiricism to your advantage. Test and learn, inspect and adapt, and make everything transparent by including design and QA considerations in your team’s estimates.
Have questions about using story point estimating? We can help. Contact our agile experts today.
