How do the Scrum Team begin Estimating User Stories and Tasks? 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 overall Requirements, and.
• Tasks, which are the activities that need to be completed in order to complete a User Story.

There is a lot of debate about Task Estimation in the Scrum Community, which we will talk about later. We will begin with the Estimation process for User Stories and why it is different from Traditional Project Estimation.

Estimating User Stories: The Scrum Approach to Product Development.

All innovation carries Risk, and Product Development is no different. At the start of bringing a new Product to Market, it is extremely uncertain that the Product will be successful, either in design or in take-up. The reduction of Risk can be Managed in many ways, such as building prototypes, Market surveys and Customer-driven design. These are all valid approaches. They are often the appropriate route to take for very expensive or intricate Products, such as a space rocket. For Software Development, Scrum takes a “Fail Fast” approach. In Scrum Projects, the Product is often not clearly understood at inception, however knowledge grows as the Development progresses. The ability to pull the plug early on a Project is important:-

• Cuts costs.
• Reduces wastage of valuable time.
• Allows the Company to move on to something new with the minimum of regret.

Of course, this approach is not always suitable for all Software Projects. Some Projects are non-negotiable, such as a legislative Requirement. While some do not bring that much Risk, such as an upgrade to an existing system. However, most Scrum Projects are started with the certain knowledge that there is uncertain knowledge about the Agile Project and 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, that will have been defined outside the scope of the Scrum Project. The Product Owner comes from the Business and is the key Roleplayer in the translation of the Product Concept into a coherent description of what must be Done to deliver the Product. Initially the Product is described in a series of Epics, usually crafted by the Product Owner or someone who can assist him, such as a Business Analyst. The Epics are a rough draft of what is required and the 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 usually 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 often lies with the Product Owner, there is no reason that the Development Team cannot undertake writing Stories, and they can be trained if they do not know how. What the Product Owner will do is define the Acceptance Criteria for each Story.

Once this is Done, Estimation can begin.

Estimating User Stories.

Initial Story Estimation is carried out in 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. There are a number of ways of accomplishing this result. Estimation tools such as “Planning Poker” could be used or point scoring systems. A Fibonacci sequence is commonly used. In this sequence the next number in the sequence is the sum of the previous two numbers. The inexperienced member would probably assign a higher number than the experienced member. A debate then begins during which a Value is assigned that the Team can agree on.

As Soon As the User Stories have been Estimated, the Development Team can select which Stories to complete in the next Sprint. The Team picks User Stories that they think they can finish during the next Sprint. They commit to getting these Stories “Done”, that is completed with all the Acceptance Criteria satisfied. The User Stories are then moved into the Sprint Backlog.

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

Estimating User Stories and Points

The amount of all the points of all the Stories in the Sprint Backlog is referred to as the Velocity. The ability to gauge exactly how many User Stories can be finished in a Sprint utilizes the Velocity of the previous Sprint as a guide. The difficulty for the Scrum Team (Scrum Master, Product Owner and Development Team) is to get the amounts right in the very first Sprint, due to the fact that they have no history to Estimate against. They can however utilize the history from other Projects if they are experienced in Scrum.

The Sprint Planning Meeting is the longest of the Sprint “Ceremonies” (Meetings) and take up to a complete day. The Scrum Master books, Facilitates and ends the Meeting, making sure that all the User Story Estimates are completed. Depending on the time utilized for Estimating and committing to User Stories, the Team can use the rest of the Meeting for Task Estimation, or might need a 2nd Meeting for this.

Estimating User Stories: Identifying 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 and fine tune the points allocated to it once the actual Tasks have been analysed. An important component of Task identification is the understanding of Task dependencies, which is also part of the Task identification process.

Once Tasks have been identified, they can be Estimated. This is where much dispute emerges in the annals of Scrum, first of all with regards to the Estimation Values, and secondly with respect to the Value of Task Estimation. There is no tough and quick guideline on what metrics to use for Task Estimation; commonly time is used, much as in Traditional Projects, however Value points can also be used again, to tie back to the User Story Estimation.

Various pundits in the Scrum Community argue for and against Task Estimation for knowledgeable Teams; there is a sensation that experienced Teams have a great intuition regarding for how long the Tasks in a Story (and the Sprint as a whole) will take them, which it is Counter-Productive to go through the process of Task Estimation for a Sprint. However, the essential word in this argument is “skilled”, and it is recommended that the Task Estimation exercise is abided by Teams that are still learning the ropes.