Agile Estimation Based on Size

Agile Methodology: Estimation based on the size of a User Story

Traditional or Agile, estimation has a critical role to play in project management. Estimation techniques in ‘Agile’ project management are radically different from that of a traditional project management owing to their fundamental differences in how they define a ‘unit’ of work.

In general sense, an estimate can be defined as the time required for accomplishing a given task. This brings into context on how to measure the size of a given work. In Agile methodology, a module of work which can provide some business value is called a ‘User Story’. A project being a collection of User Stories, if we have defined way to measure the time it takes to complete a User Story that would give us an estimate of the project.

Why estimate size instead of time?

Agile estimation methods focus on estimating the total size of a user story rather than trying to pinpoint the amount of hours it would take to complete all the tasks associated with that task. The reasoning behind this is due to the fact that in general people are not naturally very good at estimating how long a task will take to complete, especially when the task will exceed more than a couple of hours. However, people tend to be pretty good at determining with a fair amount of accuracy if one thing is larger than another, and just how much larger it appears to be. It is because of this natural ability that Relative Size estimation is so successful.

How to determine the size of a 'User Story'?

This is the tricky part as there is no standard formula on deciding the size of a User Story. This is because the rate at which work can be accomplished by a team depends on multiple factors including; experience level of the team, geographically distributed team members, domain expertise, availability of resources, as well as several other variables.

This is the tricky part as there is no standard formula on deciding the size of a User Story. This is because the rate at which work can be accomplished by a team depends on multiple factors including; experience level of the team, geographically distributed team members, domain expertise, availability of resources, as well as several other variables.

For example, let us consider that a team had worked in the past to create a ‘Login Screen’ consisting of a Username and Password text fields and the work was completed in 4 hours. This can be considered as a Story Point. Now if the same team is to create ‘User Profile’ screen consisting of 6 text fields, they may look at that user story and say that is roughly twice as large as the login screen was. Therefore, this ‘User Profile’ feature would be assigned an estimate of story points.

Team involvement in determining the size of a User Story

Just like every other aspect of agile project management, determining the size of a User Story in terms of Story Points is a collective effort, and the process for identifying and agreeing upon estimates should include all members of the agile team. The reasoning behind this is that each member may bring a different level understanding, historical experience, and technical perspective to the conversation. Therefore, you are much more likely to have an accurate representation of the actual size of a user story if you are utilizing the wisdom of the entire group rather than just a select few.

Over time Agile teams have created and utilized several activities that focus on involving all agile team members, and utilizing group wisdom to encourage discussions and identify accurate estimates. The following are brief explanations of some of the more commonly used activates:

Planning Poker using Fibonacci Numbers

For this activity, the Agile team needs to meet in a conference room or over a chat application. Each team member holds a deck of Fibonacci cards (i.e. cards number 1, 2, 3, 5, 8, 13…). A facilitator reads a story aloud, and each team member selects a card based on their best guess for the difficulty level of the task in terms of Story Points. Everyone then reveals their bids at the same time. If all the estimates are the same, you are done estimating that story; no need for discussion. However, if there is a spread, then the highest and lowest bidders get the floor to argue their cases as to why they believe the user story warrants their estimate. The game is then repeated after the high and low bidders have stated their arguments. If the new estimates are identical, the user story is estimated, and the team moved onto the next user story in the deck. If there are still one or two team members whose bids differ, then they will be asked if they can agree to the majority’s estimate. If there is still widespread variation, the discussion repeats, and the game is played again. In practice, estimates quickly converge through rounds of structured discussion.

Note that if the team decides to meet over a chat application, team members convey their individual estimates to the facilitator who then publicizes and conduct the same pattern of discussion as explained earlier.

Team Estimation Game

This technique takes the ideas behind relative size estimation and organizes them into a game like activity. For this approach, all user stories for a product backlog are printed out and placed into a deck, and a large physical area is cleared for the game to take place (either table or wall space). A single agile team member draws the first user story from the top of the deck, reads it aloud, and places in the middle of the cleared space. Another agile team member then draws the next user story from the deck, reads it aloud, and places it either to the left of the previously placed user story if they believe it is smaller, to the right of it if they feel it is larger, or directly underneath it if they feel it is the same size. The next agile team member can either draw another user story from the deck, or change the position of any of the user stories already placed (if a change is made, the team member should explain their reasoning to the team). This turn based process repeats until all user stories have been placed in relation to each other, and all agile team members agree with their current position. They may then use this layout to assign individual user stories a story point value.

How does this all help estimate a project as a whole?

Now that we have established a solid understanding of how estimation can be done using Story Points instead of hours, let us see how those estimates can be used to forecast how long a project will take to be completed. The amount of story points an agile team can commit to and complete during a given iteration is called the team’s velocity. Newly established agile teams will probably need to complete a couple iterations before they are able to accurately identify their true velocity, but once that variable has been established you may use it to gauge how large the entire project is, and roughly how many iterations will be required to complete all the user stories in the product backlog.

Example: All the user stories for a project have received story point estimations for their size, and they all add up to a total of 91 story points for the entire project. The Agile team that will be performing the work has a velocity of 20 points per iteration, and their iterations last 2 weeks. Therefore you can estimate that the project will take at least 5 iterations, or 10 weeks to complete.

Summary

There is a paradigm shift in the way estimation is done in Agile Vs Traditional Project Management environments. Project Managers who wish to adopt these methodologies should ensure that there is healthy participation of all agile team members when it comes to the estimation process, and that healthy involvement can often be accomplished through organized activities such as the ones discussed above. That said, it is important that you consider investigating alternative methods and activities so that you may find the ones that best suits your team’s unique style.

References

This article "Agile Estimation Based on Size" is from Wikipedia. The list of its authors can be seen in its historical. Articles copied from Draft Namespace on Wikipedia could be seen on the Draft Namespace of Wikipedia and not main one.

---