I believe that this quote can perfectly relate to the thought that I would like to express in this blog post about estimation in Agile. To some extent I feel that Agile nature also reflects the same behavior that you should be at-least at the edge of right instead of totally wrong, with respect to either decision making or estimation.
Here I would like to focus on Estimation, which is a very crucial part in every project. Agile has changed the concept of estimation. In traditional software development methodology, management used to estimate the project whereas in Agile, team together does the estimation of a project. Agile has introduced simple techniques for estimation – Planning poker and T-shirt sizing.
Planning poker technique has made estimations more simpler and less pressurized. Team generally uses
Fibonacci series as story points. Agile promotes standard Fibonacci series like 0 1/2 1 2 3 5 8 13 20… Fibonacci series looks like a progress bar growing from lower to higher range in terms of three factors:
Risk, Effort(not in terms of hours or days- it should be relative comparison of efforts with every user story) and Complexity.
While estimating user stories on the basis of these three factors, team makes sure to consider development, QA, Research and all other dependent tasks. All this estimation activity is done during the backlog refinement meeting.
From the bunch of user stories provided by the product owner (PO) for estimation, team first selects the easiest user story to start with and assign story points to it. Every person in the team show his/her story points for that user story. In case of differing opinions for story points between team members, they come up for discussion and present their view points for selecting that particular story point number. After discussing that user story from all the aspects team re-votes for that user story and keeps repeating the same process until all the team members converge on the same story point number, effectively agreeing on the scope and impact. And this way it becomes the benchmark for other user stories.
After analyzing the easiest user story team starts picking up the user stories from top to bottom
considering they were arranged priority wise by the Product Owner. And team finishes discussion on all those bunch of user stories given by PO. This way team ends up allocating the story points to all the user stories.
Velocity- After the team is done with estimation, during sprint planning the team decides how many story points they can pick during this sprint. Like wise team increases or decreases the story points in further sprints till they come up with the number of story points team is comfortable in picking up for the sprint. And from the experience, team keeps on improving their estimates. After two or three sprints average of story points can be considered as the velocity of the team which can be directly related to the performance of the team.
T-Shirt sizing – This is almost similar to planning poker but the only difference is instead of Fibonacci series team take sizes of t-shirts for estimation like XS, S, M, L,XL. Rest of the method of picking-up the sizes is same as in planning poker.
Team discussion on every user stories and PO presence in backlog refinement tremendously helps the team in understanding the requirements much better. Each individual’s input is important to make the estimation better and help in understanding the requirement correctly.
P.S- You can install the free “Scrum Poker” application from application stores for Android, iOS and windows smart phone which provides virtual story point cards for estimations.
