AGILE SCRUM ESTIMATION TECHNIQUES

Over time, as team members encounter new user stories, they should develop an increasingly accurate sense of how they’re going to approach stories and how much effort each user story will take to complete.

Once a team has been working together for a while, their ability to estimate new stories becomes much better. Teams with a history of past successes and failures can compare their velocity against point estimates that everyone can agree to, and as a result they can predict with reasonable accuracy how difficult it will be for them to complete a new story.

But teams new to agile sometimes have difficulty figuring out how to estimate stories effectively.

For some, the abstract and team-specific concept of points is difficult to grasp. For others, the soft relationship between point value and actual time spent working on a story can be distracting.

Until a team has been working together for a while, attempts to generate accurate point estimates for new stories may feel awkward and loose.

Here are a few estimation techniques for agile teams that can ease the transition through this phase.

These techniques get everyone engaged in productive point estimation from the start, regardless of their level of experience with agile methods.

In Scrum Projects, Estimation is done by the entire team during Sprint Planning Meeting. The objective of the Estimation would be to consider the User Stories for the Sprint by Priority and by the Ability of the team to deliver during the Time Box of the Sprint.

Product Owner ensures that the prioritized User Stories are clear, can be subjected to estimation, and they are brought to the beginning of the Product Backlog.

As the Scrum Team in total is responsible for the delivery of the product increment, care would be taken to select the User Stories for the Sprint based on the size of the Product Increment and the effort required for the same.

The size of the Product Increment is estimated in terms of User Story Points. Once the size is determined, the effort is estimated by means of the past data, i.e., effort per User Story Point called Productivity.

The estimation technique is normally chosen in such a way that the entire scrum team is acquainted and comfortable with scale’s values. The most commonly used and most popular technique is Planning Poker which is based on Fibonacci sequence.

Planning Poker Technique

In Planning Poker Estimation Technique, estimates for the User Stories are derived by playing planning poker. The entire Scrum Team is involved and it results in quick but reliable estimates.

Planning Poker is played with a deck of cards. As Fibonacci sequence is used, the cards have numbers – 1, 2, 3, 5, 8, 13, 21, 34, etc. These numbers represent the Story Points. Each estimator has a deck of cards. The numbers on the cards should be large enough to be visible to all the team members, when one of the team members holds up a card.

One of the team members is selected as the Moderator. Moderator reads the description of the User Story for which estimation is being made. If the estimators have any questions, Product Owner answers them.

Each estimator privately selects a card representing his or her estimate. Cards are not shown until all the estimators have made a selection. At that time, all cards are simultaneously turned over and held up so that all team members can see each estimate.

In the first round, it is very likely that the estimations vary. The high and low estimators explain the reason for their estimates. Care should be taken that all the discussions are meant for understanding only and nothing is to be taken personally. The moderator has to ensure the same.

The team can discuss the story and their estimates for few more minutes.

The moderator can take notes on the discussion that will be helpful when the specific story is developed. After the discussion, each estimator re-estimates by again selecting a card. Cards are once again kept private until everyone has estimated, at which point they are turned over at the same time.

Repeat the process till the estimates converges to a single estimate that can be used for the story. The number of rounds of estimation may vary from one user story to another.

Benefits of Planning Poker Estimation

Planning poker combines three methods of estimation –

Expert Opinion : In an Expert Opinion based Estimation approach, an expert is asked how long something will take or how big it will be. The expert provides an estimate relying on his or her experience or intuition or gut feel.

Expert Opinion Estimation usually doesn’t take much time and is more accurate compared to some of the analytical methods.

Analogy : Analogy Estimation uses comparison of User Stories. The User Story under Estimation is compared with similar User Stories implemented earlier. This results in accurate results as the estimation is based on proven data.

Disaggregation : Disaggregation Estimation is done by splitting a User Story into smaller, easier-to-estimate User Stories. The user stories to be included in a Sprint are normally in the range of two to five days to develop. Hence, the User Stories that possibly take longer duration need to be split into smaller Use Cases. This approach also ensures that there would be many stories that are comparable.

Conclusion

Planning Poker is an enjoyable, yet productive approach to estimating. As the session is open for discussions before the final estimate is arrived, it would easy for the team to come to a consensus and also have a broad view of the implementation of the User Story at hand.

SCRUM Estimation Methods – Estimation Poker

SCRUM Estimation Methods – Affinity Estimation

Relative Mass Valuation

When adopting agile as a new technique for a team, frequently there will be a large backlog of stories that need to be estimated all at once.

One of the biggest advantages of agile estimation is that stories are estimated relative to each other, not on the basis of hourly or daily effort. It’s usually clear to a team, regardless of their level of experience, if one story is going to be more difficult than another, even when nobody has any idea how long it may take to complete individual stories.

But going through the process of individual point estimation for a huge list of stories can be daunting.

Relative mass valuation is a quick way to go through a large backlog of stories and estimate them all as they relate to each other.

To use this approach, first write up a card for each story.

Then set up a large table so the stories can be moved around easily relative to each other.

Pick any story to start, then get the team to estimate whether they think that it is relatively large, medium, or small.

If it’s a large story, place it at one end of the table. If it’s a small story, it goes at the other end of the table. A medium story goes in the middle. Now select the next story and ask the team to estimate if it’s more or less effort than the story that you just put down. Position the story card on the table relative to the previous card, and go to the next card.

Using this technique, it’s possible to go through 100 or more backlog stories and estimate their relative effort in as little as an hour.

Everyone on the team will feel a sense of accomplishment when they see the scope of their work laid out in front of them, estimated in order of effort.

The next step is to assign points values based on the position of the stories on the table. Start with the easiest story that is worth assigning points to, and call it a 1.

Then move up the list of cards, assigning a value of 1 to every story until you get to one that seems at least twice as difficult as the first one. That story gets a 2.

You may need to remind the team not to get caught up in the fine details. The idea is to get a rough point estimate, not a precise order.

Ultimately, any story may be completed in any order based on the business value and priority assigned by the product owner, so all the team needs to estimate is how many points one story will take relative to another.

Conclusion

Using these simple techniques, it’s surprising how quickly a team with no pre-existing concept of point values can come to a very clear understanding of the relative value of all the different stories they’re faced with, even before they’ve established an effective team velocity.

The sooner your team starts estimating points and tracking their effort, the more effective point valuations will become.

Eventually, every team can become more adept at estimating new stories and develop its own scale for points that will factor into its own individual velocity.

Was this helpful?

Click on the link to know more on Agile Scrum Methodology and steps to follow to implement in your projects