The Importance of Ready User Stories
User stories in Scrum are work items that the team implements and turns into working software. The product owner is mainly responsible for developing user stories. However the team will have to work with the product owner to refine the user stories to ready user stories. This means the stories must be clear, concise, and immediately actionable. I’ve personally seen many teams struggling through the sprint, holding endless debates and get nothing done by the end of the sprint. The reason was simple that the user stories were not actionable and the result was frustration amongst team member as well as product owners.
To get the user story ready, the product owner will put the user stories in the product backlog. During backlog refinement, the product owner and team will work to get the user stories ready. This will mainly involve making them actionable. The team should be able to estimate the amount of work involved in a story and what they can take in a sprint. A user story can be said to be ready if the team can agree that it can be done. From my point of view this the teams agreement that a story is refined good enough to go into a sprint is very vital. The team then gets involved and takes ownership for implementation instead of typing in code they don’t really identify with. Furthermore, ready user stories enable the team to determine what needs to be done and the amount of work needed to complete the user story. Tests need to be done to demonstrate that the user story is done.
Acceptance criteria are an important aspect of a ready user story. For a project to be termed successful, the team has to meet the acceptance criteria. It can be defined as the conditions that must be satisfied by the team for the product owner to accept the software. At times, the acceptance criteria are not well documented and might be perceived. To avoid any problems arising at the end of a sprint or at release, we need to clearly define the acceptance criteria. A clearly defined acceptance criteria ensures customer satisfaction. The team is also able to determine if they did the right thing. Another benefit that I see in acceptance criteria is, that it gives you an indication whether a user story might be too big very early. From experience 3-5 acceptance criteria per story are a healthy measure.
Having a ready user story is extremely useful to the team as the consequences of the opposite are disastrous. It can lead to duplication of work or the team can take a wrong direction different from the vision of the product owner. Having ready user stories has a positive impact on the productivity of the team. It also saves on time and effort. User stories as a part of an agile approach emphasize more on talking about the requirements rather than writing blocks of text. Texts can be interpreted differently by different people, but conversation is more precise and clarifications can always be sought. User stories are normally a sentence or two which can then be divided in a series of conversations that describe the desired functionality. When working with user stories you should always keep in mind the principle of the Agile Manifesto, that says that the most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Another benefit of having ready user stories is that it invites negotiation and there will be noticeable movement in the backlog during sprint review. Normally, the user stories from the product owner will be epic- that is they will be big user stories, however after revision; they will be broken down to smaller chunks that hold enough detail.
Nevertheless, user stories should not have too much detail or be too formal. Product owners or users of the software can write too much text. This carries the risk of skipping conversation which is an important aspect of agile development, with the assumption that everything is covered in the text. This can lead to overlooking of some of the customer’s needs or vision. Technical tasks should also be avoided in user stories.
Reads:
Leave a Reply