Scrum : Developing User Stories in a Scrum Project

In a Scrum project, the responsibility for creating User Stories generally lies with the Product Owner(s). User Stories ensure that the customer requirements are clearly depicted and are understood by all the key internal and external stakeholders including the Scrum Team who deliver the outputs of the project. In Scrum, the User Stories and the associated Acceptance Criteria are generally developed together by the Product Owner.

Before we discuss the process of creating User Stories, let’s understand what User Stories are. User Stories adhere to a specific, predefined structure and are a simple way of documenting the requirements and desired end-user functionality. The requirements are expressed in the form of User Stories which are short, simple, and easy-to-understand statements. A User Story tells you three things about the requirement: who needs the requirement, what is the requirement, and why is the requirement needed. Some User Stories may be too large to be handled within a single Sprint. These large User Stories are often called Epics, and once they come up in the Prioritized Product Backlog and are to be developed in the upcoming Sprint, they are further decomposed into multiple smaller User Stories.

Now, let us understand process of creating User Stories in detail. Following are required to develop User Stories: Scrum Core Team, Prioritized Product Backlog, Done Criteria, and Personas. The tool used to develop the User Stories is User Story Writing Expertise. And along with User Stories, the team will also develop User Story Acceptance Criteria.

Here is a video on how User Stories are created: http://www.scrumstudy.com/watch.asp?vid=612

Although the entire Scrum Core Team needs to be involved in creation of the User Stories, it is the Product Owner who decides the User Stories as he/she creates the project’s initial overall requirements, determines Product Vision, assesses the viability and ensures delivery of the product or service, decides minimum marketable release content and, ultimately, provides Acceptance Criteria for the User Stories to be developed in the ensuing Sprint. However, the Scrum Team can seek clarifications from the Product Owner and also pass on expert opinion on creation of User Stories.

An important influence on the development User Stories is the Prioritized Product Backlog. It is based on three primary factors: value, risk or uncertainty, and dependencies. Other important inputs are Done Criteria and Personas. Done Criteria are a set of rules that are applicable to all User Stories. A clear definition of Done is critical, because it removes ambiguity from requirements and helps the team adhere to mandatory quality norms. A User Story is considered Done when it is demonstrated to and approved by the Product Owner who judges it on the basis of the Done Criteria and the User Story Acceptance Criteria. Personas are highly detailed fictional characters, representative of the majority of users and other stakeholders who may not directly use the end product. Personas are created to identify the needs of the target user base. Creating specific Personas will help the team understand users and their requirements and goals better. And thus help develop appropriate User Stories.

User Story Writing Expertise is the exercise or tool used to develop the User Stories. The Product Owner, based on his/her interaction with the stakeholders, his/her own business knowledge and expertise, and inputs from the team, will develop the User Stories that will form a part of the initial Prioritized Product Backlog for the project. The Prioritized Product Backlog represents the sum total of what must be completed during the project. The objective of this exercise is to create elaborated and refined User Stories that the Scrum Team commit to. Although the Product Owner has the primary responsibility for writing User Stories, and often carries out this exercise on his/her own, a User Story Writing Workshop can be held if desired.

Finally, let’s conclude by discussing how best to present a User Story. The format for presenting a User Story as given in the Scrum Body of Knowledge (SBOK™) is: ‘As a <role/persona>, I should be able to <requirement> so that <benefit>’. An example for this could be ‘As a Database Administrator, I should be able to revert to a selected number of database updates so that the desired version of the database is restored.’ The use of predefined, standard format helps in enhanced communication among the stakeholders and better estimations by the team.

Scrum Sprint : How are Changes to a Sprint Managed in Scrum?

In Scrum, all requirements related to an ongoing Sprint are frozen during the Sprint. No change is introduced until the Sprint ends, unless a change is deemed to be significant enough to stop the Sprint. In the case of an urgent change, the Sprint is terminated and the team meets to plan a new Sprint. This is how Scrum accepts changes without creating the problem of changing release dates.

If there is a Change Request that may have significant impact on a Sprint in progress, the Product Owner, after consultation with relevant stakeholders, decides whether the change can wait until the next Sprint or represents an urgent situation which may require ending the current Sprint and starting a new one. Scrum framework clearly specifies that the scope of a Sprint cannot be changed once the Sprint begins. If the required change is so important that the results of the Sprint would be worthless without it, then the Sprint should be terminated. If not, then the change is incorporated into a later Sprint. This is illustrated by the following diagram:

There is only one exception to this rule about not changing the scope of a Sprint once a Sprint begins. If the Scrum Team determines it has heavily overestimated the effort during the Sprint and has spare capacity to implement additional User Stories, the team can ask the Product Owner which additional User Stories should be included in the current Sprint.

Here is a video on this topic: http://www.scrumstudy.com/watch.asp?vid=591

By locking down the scope of every Sprint, the team is able to efficiently optimize and manage their work and effort. An additional benefit is that the team does not have to worry about managing changes once they start working on a Sprint. This is a big advantage of the Scrum framework as compared with traditional project management. In traditional project management, changes can be requested and approved anytime during the project’s lifecycle. This often creates confusion for project team members, decreases team motivation due to discontinuity, and results in a lack of focus and the team feeling that “nothing ever gets done.” On the other hand, in Scrum projects, changes are not allowed once a Sprint starts. This ensures that in every Sprint, the team completes deliverables and tasks are Done. Furthermore, the business recognizes tangible benefits from potentially shippable Deliverables at the end of each Sprint.

Moreover, since the Product Owner and Stakeholders are aware that changes are not allowed once a Sprint begins and a Sprint lasts between 1 and 6 weeks, they define and prioritize requirements during the appropriate processes of Create Epic(s), Create Prioritized Product Backlog, and Groom Prioritized Product Backlog.

Scrum Project Delivery : How Does Scrum Enable Organizations to Achieve Flexibility in Project Delivery?

Scrum helps organizations become more flexible and open to change. However, it is important to understand that although the Scrum framework emphasizes flexibility, it is also important to maintain stability throughout the change process. In the same way that extreme rigidity is ineffective, extreme flexibility is also unproductive. The key is to find the right balance between flexibility and stability because stability is needed in order to get work done. Therefore, Scrum uses iterative delivery and its other characteristics and principles to achieve this balance. Scrum maintains flexibility in that Change Requests can be created and approved at any time during the project; however, they get prioritized when the Prioritized Product Backlog is created or updated. At the same time, Scrum ensures that stability is maintained by keeping the Sprint Backlog fixed and by not allowing interference with the Scrum Team during a Sprint.

In Scrum, all requirements related to an ongoing Sprint are frozen during the Sprint. No change is introduced until the Sprint ends, unless a change is deemed to be significant enough to stop the Sprint. In the case of an urgent change, the Sprint is terminated and the team meets to plan a new Sprint. This is how Scrum accepts changes without creating the problem of changing release dates.

Scrum facilitates flexibility through transparency, inspection, and adaptation to ultimately achieve the most valuable business outcomes. Scrum provides an adaptive mechanism for project management in which a change in requirements can be accommodated without significantly impacting overall project progress. It is necessary to adapt to emerging business realities as part of the development cycle. Flexibility in Scrum is achieved through five key characteristics, which are shown in the ensuing diagram: iterative product development, Time-boxing, cross-functional teams, customer value-based prioritization, and continuous integration.

Scrum also enables achievement of flexibility through time-boxing. Time-boxing refers to setting short periods of time for work to be done. If the work undertaken remains incomplete at the end of the Time-box, it is moved into a subsequent Time-box. Examples of Time-boxing include limiting the Daily Standup Meetings to 15 minutes and setting Sprint durations to be one to six weeks. Time-boxes provide the structure needed for Scrum projects, which have an element of uncertainty, are dynamic in nature, and are prone to frequent changes. Time-boxes aid in gauging the progress of the project and allow the team to easily identify when they may need to modify a process or approach.

Time-boxed Sprints contribute greatly toward meeting deadlines and achieving high levels of productivity. Sprints promote order and consistency in a volatile work environment. They provide a platform to gauge results and obtain feedback in a short span of time. Sprints also allow for frequent assessment of progress and the methods used to manage the project, including effective change management. Errors or problems can be identified early and can be rectified quickly.

By using Time-boxing in Sprints, the team frequently revisits the process of estimating the work to be done, so the projection of time and effort required becomes more accurate with each subsequent Sprint as the project progresses. These iterative cycles also motivate team members to achieve projected targets and incremental goals toward reaching the larger objective.

Here is a video on change management in Scrum: http://www.scrumstudy.com/watch.asp?vid=590

Organizations also achieve flexibility due the fact that Scrum facilitates flexibility through cross-functional and self-organized Teams. Self-organization ensures that Scrum Team members determine on their own, how to do the work of the project without a senior manager micromanaging their tasks.  Having cross-functional and self-organized teams allows the group to adapt and effectively manage the ongoing work and any minor issues or changes without having to obtain support or expertise from members outside the team, and in the process, create deliverables that are ready to be shipped if necessary.