What are Scrum Story Points and how are they used for estimating User Stories Within Scrum Projects? While Scrum does not follow Traditional Project Management guidelines, there are some Estimation activities around the Work to be Done. Estimation is Done for:-.

• User Stories, which are subsets of the general Requirements.
• Tasks, which are the activities that need to be completed to complete a User Story.

There is a great deal of argument about Task Estimation in the Scrum Community. We will begin with the Estimation process for User Stories and why it is different from Traditional Project Estimation.

Scrum Story Points: The Scrum Approach to Product Development.

All development carries Risk, and Product Development is no different. At the start of bringing a brand-new Product to Market, it is very uncertain that the Product will be successful. Uncertainties are around both product design and product take-up. For Software Development, Scrum takes a “Fail Fast” approach. This is where the Product is not clearly understood at inception, but the knowledge grows as the Development progresses. The ability to pull the plug early on a Project is important:-

• saves costs.
• minimizes waste of valuable time.
• allows the Company to proceed to something new with the minimum of regret.

Naturally, this approach is not always appropriate for all Software Projects. Some Projects are non-negotiable, such as a legal Requirement. Some Projects do not bring that much Risk, such as an upgrade to an existing system. Many Scrum Projects start with the understanding that there is uncertain knowledge about the Project. At this stage there is a low Confidence level in Project success.

The Evolution of a User Story.

At the start of a Project there will only be a Product description available. This description will have been specified outside the scope of the Scrum Project. The Product Owner comes from the Business and is the essential Roleplayer. They are pivotal in the translation of the Product Concept into a meaningful description of what must be Done to deliver the Product. Initially the Product is explained in a series of Epics, generally crafted by the Product Owner (the Voice of the Customer) or someone who can assist him, such as a Business Analyst. The Epics are an outline of what is needed and the very first layer of granularity.

The Product Owner prioritises these Epics and houses them in the Product Backlog. Once this has been accomplished, the Epics can be broken down into User Stories. A User Story is generally the smallest possible Requirement that can be extracted from an Epic, and the lowest level of granularity. This is Done in the Scrum process “Create User Stories”. While this Responsibility typically lies with the Product Owner, there is no reason why the Development Team can not carry out composing Stories. They can be trained if they do not know how. The Product Owner will also specify the Acceptance Criteria for each Story. Once this is Done, Estimation can begin. The techniques used for User Story Estimation can be reviewed during the Sprint Retrospective.

Scrum Story Points: Estimating User Stories.

Initial Story Estimation is carried out during the Sprint Planning Meeting. This is not an Estimation of time, such as duration and Effort in Project Planning, it is an Estimate of Complexity. Each Team member could come up with a different Value, based on their own experience. A democratic process is then undertaken to derive a Story Value that fits most of the Team’s Estimations. There are several ways of attaining this outcome, using Estimation tools such as “Planning Poker” and different point scoring systems.

A Fibonacci sequence is commonly used (where the next number in the sequence is the sum of the previous two numbers), ranging from 0 to 100. The inexperienced member would probably assign a higher number than the old hand, and a debate then begins during which a Value is assigned that the Team can agree on.

When User Stories have been Estimated, the Development Team can choose which Stories to include in the next Sprint. These Stories are picked from the prioritised Product Backlog. The Team picks User Stories that they think they can finish throughout the next Sprint and commit to getting these Stories “Done”. A User Story being done means that it is finished and all the Acceptance Criteria are satisfied. They are then moved into the Sprint Backlog.

The sum of all the points of all the Stories in the Sprint Backlog that have been completed is known as the Velocity. The ability to gauge precisely the number of User Stories that can be finished in a Sprint uses the Velocity of the previous Sprint or sprints as a guide. The challenge for the Scrum Team is to get the sums right in the first Sprint. This is due to the fact that they have no history to Estimate against. They can however utilize history from other Scrum Projects if they are experienced in Scrum.

We found these books great for finding out more information on Agile Scrum:

The Sprint Planning Meeting is the longest of the Sprint “Ceremonies” (Meetings) and can take up to a full day. The Scrum Master books, Facilitates and ends the Meeting, making sure that all the User Story Estimates are finished. Depending on the time used for Estimating and committing to User Stories, the Team can use the remainder of the Meeting for Task Estimation, or may require a second Meeting for this. Tasks should be kept small enough that each Task can be completed within one day. This ensures that the Daily Standup meeting can report on a completed task each day.

Scrum Story Points: Determining and Estimating Tasks.

A Task is an activity within a User Story, such as “clear test base and repopulate with test information”. Each User Story is broken down into Tasks by the Development Team. This gives an Opportunity to Refine the size of a User Story. The Scrum Team can fine tune the points allocated to it once the Tasks have been analysed. An important component of Task identification is the understanding of Task dependencies. This is part of the Task identification process.

There is no hard and fast rule on what metrics to use for Task Estimation. Frequently time is used, much as in Traditional Projects, but Value points can likewise be utilized. This ties back to the User Story Estimation. Various pundits in the Scrum Community argue for and against Task Estimation for experienced Teams. There is a feeling that experienced Teams have an excellent intuition as to how long the Tasks in a Story (and the Sprint as a whole) will take them. It is therefore Counter-Productive to go through the process of Task Estimation for a Sprint.