Estimating an agile User Story

Image Source: https://tech.gsa.gov

In my previous article, I talk about the nuances of a User Story. Now that we know what goes in a user story, the next task is to tag each story with an estimation.

An estimation is the process of predicting how much effort a team will need to complete a user story.

An estimation for a user story assists in laying out the plan/timeline for a sprint/release for the team and/or the client.

People often confuse estimation with number of hours, days, weeks and so on. While it may be mapped to those parameters in a longer run as the team commence with the delivery but, expecting it in an early stage can be a bit cumbersome.

There are various ways using which a team defines the estimation.

• Using a Fibonacci number e.g. 1, 2, 3, 5, 8 …
• Using T-Shirt sizing e.g. XS, S, M, L, XL …

There is a concept of no-estimates which is quite popular lately. More about it maybe, in a separate article.

Let’s understand the Do’s and Don’t for effective story estimation:

Do’s

• Always break your stories into smaller chunks(more about user story breakdown in a separate article).
• For an estimation, one should mostly consider the complexity of the work involved. For e.g. external circumstances like unavailability of APIs, absence of proper information, people going on leaves etc. should not impact an estimate.
• One should account for the skill and experience present in the team(if the entire team is going to work on these stories, else attributes of the individuals).

Don’t

• Never ignore opinion of any team member who is a part of the estimation exercise. If there is a conflict with the estimation provided, give people a chance to justify their understanding, provide missing information(if required) and build a consensus.
• Rush into the estimation process, it takes time, let it be.
• As suggested by a colleague, don’t go hyper crazy with estimates trying to make them accurate.
• Another one, don’t go overboard with tech implementation details while discussing.

How to conduct an estimation session with the team?

• Ask the entire team to be a part of the meeting(not just the devs, but QAs as well).

You may wonder why QAs are needed in an estimation session, simple answer, as a team you may want to understand the bottleneck of work at hand. For e.g. a logo change in an application can be a minuscule task for a developer but to validate the change in an entire application(for example) can take a lot of time for a QA(yes, writing tests are part of estimation whether Unit/Integration/Functional).

• Lay down the stories in front of the team(post-its / mural board / jira board whatever works for the team).
• Make sure everybody understands the work(task list) required to be done for each story.
• Identify the story for which least effort will be required as this story becomes a benchmark for rest of the stories(in terms of complexity of the work).

For e.g. creating an API endpoint to fetch flight details of all operators for a single route may be more complex vs. fetching them for a single operator after the former is implemented. This is called Relative estimation.

• As mentioned in the Do’s section, do not bloat your estimation with circumstantial dependencies.
• Once you as an individual thinks of a number(fibonacci) / T-shirt size, provide it to the facilitator(you can either tell them privately or everyone can reveal theirs on a count of 3…2…1).

If you are wondering who facilitates the estimation session, in my experience, I have seen mostly BAs facilitating it. But, anyone with an open mindset is welcome to do so.

• If there is a common understanding, you as a team are most likely to get the same number/size as an estimate but, if there is a conflict, make sure to follow the first point mentioned in the Don’t section above.
• Once there is a consensus, you put the estimate on the story and move to the next one.

During the course of the delivery, you’ll notice that what seemed an XL(for example) for a task in the past has become an M or L today, and that’s OK. The team now knows what needs to be done for a similar task as their context has increased over time. Don’t let the past estimates influence your future ones.

Few FAQs regarding story estimation:

My client asks for estimation in terms of hours/days/weeks?

First of all, tell them that once the team is already in the execution phase for a couple of sprints, this can be extracted by analysing when a story was picked and finished and this data builds over time.

If they are still persistent, you can always maintain a mapping table but make sure to highlight that the data is subjected to change and is built based on assumptions with the information at hand.

My client wants to get involved in the estimation process.

Why not, story estimation is a collaborative effort, if the client wants to be a part of it, they are always welcomed. This way, the estimation exercise becomes more transparent.

Here are some questions that a client may ask about story estimation:

• How do you estimate the size and complexity of a story?
• How accurate are your estimates?
• What factors do you consider when estimating stories?
• Can you provide examples of how you have used estimation in the past?
• How do you handle uncertainty or risk in your estimation process?
• How do you revise your estimates if the scope or requirements of a story change?
• How do you use estimation to plan and manage your work?
• How do you measure the team’s velocity and capacity?

More about planning and velocity in a later article.

PS: I hope I have given you enough arsenal to kickstart the estimation process. It has not been easy to pen these thoughts in a smaller article as I don’t want you to struggle and find alternate resources for more information. While, you may want to but above can aid you with sufficient data points to get started.