The first step in approving, estimating and committing to User Stories is Developing Epics. The Software Development Lifecycle starts with the seeds of an idea in somebody’s mind. This seed of an idea is translated into a feature Epic which eventually equates into something Deliverable and executable. This journey, where the idea is identifies, 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 decomposed Epics, which can be described as a short description of a specific Requirement. Some of the activities that result in User Stories that can be Developed and completed by the Scrum Development Team occur in the Planning and Estimation Phase. Before one can approve, Estimate and commit to User Stories, there are some prior processes in the Initiate Phase that we need to take into account.

Initiate Phase – Developing Epics

The Initiate Phase covers the beginning of a Scrum Project. This includes the strategy definition embodied in the Project Vision. The Initiate Phase also covers the selection and on-boarding of the Scrum Project resources and preliminary Release Planning. There are two processes which relate to Requirements definition, namely:-

• Developing Epics.
• Creating the Prioritized Product Backlog.

These 2 processes form the basis for the content of User Stories to be Developed. They also highlight their relative importance in delivering the finished Product.

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

Developing Epics: The Product Backlog

The Product Backlog is the repository for all the Epics, User Stories and any other Documentation describing the Requirements. The Product Owner prioritises the Backlog, specifying which Work needs to be Done first. This is based on Risk, Value to the Project and the variety of dependencies on the item in question. Initial Acceptance Criteria are likewise defined at this stage. These Criteria will be used by the Scrum Product Owner to determine whether a User Story in a Sprint is “Done”.

Developing Epics: Planning and Estimating Phase

User Stories are created as elaborations of the Epic. They are a granular description of a Requirement within the Epic. In Scrum literature, the function of producing the User Stories is typically assigned to the Product Owner. In truth, while the Product Owner has the best insight into the Work to be Done, the Work is typically performed by Business analysts, who might be part of the Scrum Development Team.

Acceptance Criteria

A really important output from this process in the Acceptance Criteria. This output is both for an individual User Story and for the overall Product context. The Acceptance Criteria should be discussed with and understood by the Scrum Development Team. When a User Story has been Developed, the Product Owner checks and verifies that all the Acceptance Criteria have actually been met, as well as the broader Project Criteria.

In addition, a rough Estimate of the complexity of each User Story is Done in preparation for the choice of Stories for the Sprint. The Product Owner approves a set of Stories that he thinks will be viable for the Sprint. The ultimate decision on what goes into the Sprint is covered in the next 2 processes, and is made by the Scrum Development Team, and not the Product Owner.

Developing Epics: Estimate User Stories.

The Scrum Team (Agile Scrum Master, Scrum Product Owner and Scrum Development Team) choose which User Stories are to be included in the Sprint Backlog. The main result of the Sprint Planning Meeting will be a firmer Estimate of each User Story. This allows the Scrum Team to choose which Stories to include in the Sprint. The Product Owner helps in this process by describing the Stories and providing any background info. The Team then uses a range of approaches to Estimate the Effort required for each Story. These user story estimates are expressed in Story Points, not time.

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

Developing Epics: Commit User Stories.

Now that each User Story has been allocated a number of points for the Sprint, the number of Stories that can be completed 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 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 Stories are transferred to the Sprint Backlog. The next stage will be to identify the Tasks within each Sprint. A Task must not surpass more than one working day. This is due to the fact that each Team member will explain the Work they did the previous day and the Work they will do today in terms of Tasks. Clearly, if a Task goes beyond one day, it would not be a good prospect for measuring development, unless the Task will be finished by two Team members Working together.

What Happens Next?

The Team can now begin the Sprint. Once they have completed the sprint deliverables, a Sprint Review meeting is held so that the Scrum Development Team can demonstrate the deliverables for acceptance by the Product Owner.