Estimating user stories in software projects

Almost every software project nowadays deals with user stories for requirements and managing backlog. We estimate stories with some yardstick and try to find out how long it will take to complete the piece of functionality. Often times these estimates deviate from reality for variety of reasons causing projects to derail or raising questions on the mechanism.

Over a period of time, I moved from products to services and from one project to another. As a Business Analyst I was part of several estimation discussions and each of them was a new experience. I am no expert in this space but observed some patterns and tried to learn from them. These learnings helped identifying the blind spots related to estimates and build certain indicators to gauge the health of product backlog.

Learning #1 : Story sizes are estimates of functionality - nothing less, nothing more

We can argue that there’s not much of a difference between size and estimate, and I don’t disagree. In spite of that, changing that word helped. Somehow everyone who wanted to know when it will get over associated estimates with timeline. And that’s alright , it’s the need of business. But process of arriving at timeline needs more than just points. Notions of estimates vary from people to people, their prior experiences influence it. People carry their previous project’s understanding to the new project e.g. “1 point is equivalent to what team can wrap up in 1 or 2 days”, “usual project velocity is 8 pts per iteration” etc. Having such implicit assumptions could lead to misunderstandings. When I swapped the word “estimate” with “story size”, it changed the perspective for everyone - including me.

Learning #2 : Functional slicing is the only way to break the stories

Unless we are sizing stories in a well established project, estimates will come in existence during inception or workshops. Information available at this point in time is limited and we will have to make bunch of assumptions. We have a high level or limited idea of ecosystem in which the product is going to fit in. Sometimes even tech stack is not defined.

So, it is important to carve out and estimate stories with functional slices in such cases rather than UI or API or Database stories e.g. -

• Creating a request form to cater one of the happy paths (UI to DB)
• Display transactions for account based on date criteria

Enhancing form for other scenario or adding more criteria could be enhancement stories. Having functional stories ensures that the product evolution is incremental and not lopsided.

There can be numerous ways but essentially slicing stories based on functional nature helps to keep user in focus.

Estimating stories in terms of technical components is rarely a good idea.

Learning #3 : Estimates are relative

At different points in time, different people may be involved in story sizing activity. To ensure new stories and previously sized ones can be looked at together, it is important to maintain relativity.

It pays to identify baseline stories with detailed discussion.Identify reference stories upfront and make everyone aware of them.

Define 1 ptr, 2 ptr, 3 ptr and … stories at the beginning, spend some time in discussing them in bit more details. Using these as references speeds up sizing exercise and maintains relativity.

As project progresses, team eases into tech stack, code familiarity and complexity. Subsequent sizes start getting compressed. Keeping base stories in perspective helps to ensure we don’t get aggressive in estimates and progress is demonstrated through increased velocity.

Learning #4 : Sizing Integration stories and factoring in dependencies

Rarely we build something which sits in isolation. Integration with other systems is inevitable. Identify such integration points clearly and label them. Integrations are usually uncertain and we have tendency to be cautious about them. That’s natural but uncertainty can not be estimated. My preference is always to estimate with clear assumptions. It not only sets the scope clearly but also provides precise revisit triggers for integrations when assumptions are voided.

This takes me to a couple of key concepts which many have already spoken about but not so much seen in practice continuously -

• Completeness
• Volatility

Learning #5 : Completeness and Volatility are essentials

Completeness is something which indicates confidence in understanding of story. Spectrum could be from complete to unknown.

Volatility talks about how likely it is for the story understanding to change. One could simply measure it with low, medium and high.

It’s important to not get caught into over detailing. Idea is to get understanding quickly. While there is no definite answer to what granularity is good, keeping spectrum just 3 values wide, serves the purpose.

Rather than values it’s the process of looking at every story through these 2 lenses does the trick. These questions provides quick directions to analysis. Looking at stories with 3 parameters viz. size, completeness and volatility, can tell important story of the backlog.

Higher degree of completeness with lesser volatility is excellent. But when more stories are volatile or less complete, it’s a signal to ensure closer look.

Re-estimates

Things don’t change much even in case stories need to be re-estimated. However we need to keep in mind the impact on relative story sizes on backlog post re-estimation.