Task Estimation in essence starts with the Software Development Lifecycle taking a germ of a concept in somebody’s mind. This germ is then fleshed out, estimated and then translated into something Deliverable and executable. This journey, where the concept is Captured, explained, Refined and translated, is the magic of Software Development. In Scrum, part of the process is the Development of User Stories. User Stories are quick descriptions of a particular Requirement.

Some of the activities that result in User Stories that can be Developed and finished by the Scrum Team (Scrum Master, Product Owner and Development Team) take place in the Planning and Task Estimation Phase. Prior to approving, Estimating and committing to User Stories there are some processes that we need to take into account.

Developing Epics and Creating the Product Backlog.

The Initiate Phase covers the start of an Agile Scrum Project. It includes the strategy definition embodied in the Project Vision. The Initiation Phase also covers the selection and on-boarding of the Scrum Project resources and initial Release Planning. There are two processes which relate to Requirements definition, these are:-.

• The Development of Epics
• The Creation of the Prioritized Product Backlog

These two processes form the basis for the content of the User Stories. They define the user stories relative importance in delivering the finished Product.

‘ Epics’ are the very first cut of User Stories. They are Requirements painted with a broad brush. They are not precise enough to Develop from. Each Epic can be regarded as a book which can be separated into chapters. These chapters will be the User Stories. At this stage, Personas can be Developed. Personas are characters that can be used as the subjects for the User Stories. They represent the requirements and wishes of the Customers and Stakeholders in the Agile Project.

Task Estimation and The Product Backlog

The Product Backlog is the repository for all the Epics, User Stories and any other Documentation that describes the Requirements for the Product. The Product Owner prioritises the Product Backlog. It is also the Product Owner who specifies which Work requires to be Done first. This is based upon Risk, Value to the Agile Project and the number of reliances on the product in question. The User Story Acceptance Criteria are defined at this stage. These Acceptance Criteria will be utilized by the Product Owner. The Product Owner uses this information to determine whether a User Story in a Sprint is “Done” (or finished) or needs additional Work.

The Epics and the Prioritized Product Backlog form the foundation for the writing of User Stories. These User Stories selected for a Sprint and for inclusion within the finished Product element.

Planning and Task Estimation

User Stories are developed as elaborations of the Epic. In Scrum literature, the function of creating the User Stories is generally assigned to the Product Owner.

An extremely important output from this process are the Acceptance Criteria. The Acceptance Criteria are to be discussed and understood by the Development Team. When a User Story has been Developed, the Product Owner examines and validates that all the Acceptance Criteria have been met. The Product Owner also validates that the deliverables meet the broader Project Criteria. If this happens, the Work will be “Done”.

In addition, a rough Estimate of the Complexity of each User Story is conducted. This is in preparation for the selection of User Stories for the Sprint. The Product Owner approves a set of User Stories that they believe will be viable for the Sprint. The ultimate choice on what enters into the Sprint Backlog is covered in the next 2 processes. This decision is made by the Development Team, not the Product Owner.

Task Estimation & User Stories.

The Scrum Team meet with the Product Owner to choose which User Stories are to be included in the Sprint Backlog. The primary outcome of this Meeting will be a firmer Estimate of each User Story. This allows the Scrum Team to decide which Stories to Include in the Sprint.

The Team may discover that they can include all the approved Stories in the Sprint. They might however need to exclude some Stories if they want to complete the Sprint in the agreed time. They can now commit to the User Stories for the Sprint.

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

Task Estimation & Committing to User Stories.

Now that each User Story has been allocated a number of points for the Sprint, the number of Stories that can be finished in the Sprint are decided. The Velocity is the overall number of points for all the User Stories completed in the previous Sprint.

When the Development Team has Identified which User Stories will be included in the Sprint, they commit to completing the Work on the Stories and satisfying the Acceptance Criteria. The committed User Stories are moved to the Sprint Backlog. The next stage will be to determine the Tasks within each Sprint.

What Happens Next?

The Team can now begin the Sprint. The Product Owner will have the final say on whether Work has actually been “Done”, based on the Acceptance Criteria. A Sprint Review Meeting is held at the end of the Sprint. Within this meeting the Stakeholders are invited to come and hear of the Team’s progress. The stakeholders get an update on how the journey to final Product is advancing. Following this, the next Sprint cycle begins.