In this article, we are going to discuss what constitutes completing a user story in Scrum, or in other terms, what is necessary for the project team to mark the story as done during a sprint. There sometimes is a misunderstanding about what this means, however, there is flexibility here depending on the type of software being developed, and how the software will be used. Let’s explore this in more detail.

User Stories

Scrum has several ceremonies that occur repetitively throughout the project such as product refinement, sprint planning, daily scrum, retrospective and showcase, but when stories are actively being worked on, how does the team know that the story has been completed? How does the team know that they have built what the user wants? Let’s revisit the purpose of a user story in Scrum. It’s essentially a tool to capture a description of what the user wants the system to perform from an end-user perspective. It comes in the form of who, what and why. The use story description is broken down into three parts outlining the type of user (who), what they want the system to do (what) and why they want it (why). The description should contain enough information to let the development team understand what the business value is, however, there is scope for ambiguity here. This can result in something being developed that wasn’t wanted or needed, which results in a waste of resources. Let’s give an example of this.

As a Marketing Manager

I want the system to send bulk emails to specific people

So I am able to let them know of upcoming events

Now, when the development team works on this story, how do they know what they have built is what the Marketing Manager wanted? They may be a mismatch between what a develop perceives how the system works vs how the marketing manager wants this to work. Also, the exact functionality of the system isn’t clear e.g. how the screen would work, who the emails are sent to, how emails are sent out and how they would create the emails. From the current story description, it isn’t clear enough exactly what needs to be built. So, what is missing?

Acceptance Criteria

In Scrum, to ensure what has been built is what the user wanted, acceptance criteria are added to the story. Acceptance criteria refers to a set of predefined requirements that must be met to mark a user story complete from the perspective of the end user. Acceptance criteria defines the feature’s behaviour and how the system should operate. Having this as part of the story, enables the developers to understand what the business value is for the story, whilst also outlining the system’s requirements and how it should operate. Based on our example, acceptance criteria for this might look like the following.

I am able to copy and past a template from word into the email sending screen

I am able to select which target segment from the existing list in the system to send it to

I am able to preview the email before sending

I am able to send the email and it will run in the background

I will be notified when the send has completed

So if the developer builds the system to what the user want’s based on the user story description and acceptance criteria, can the story be marked as done? The answer is maybe. This may hold true for some teams, but it might not be enough for others. The fact that you can build something based on a user story and its acceptance criteria doesn’t mean that its complete. Complete is deterministic on what type of software you are building, how often you are releasing the software and your team’s development requirements. In Scrum, to mark something as done, means that specific criteria must be completed on a story for it can be considered done. The criteria can vary from project to project, but it is necessary to have the criteria defined at the beginning of a sprint. Scrum refers this to as the definition of done.

Definition Of Done

As an example, a User story will need to be developed, peer reviewed, tested and product owner approved before it is marked as done. Other criteria may be to bundle/package and update user documentation before it is marked as done. The thing to note here is its all dependent on what the team agrees the criteria is. The ideal notion of a story being complete could be is it is a shippable product that the business can start getting value from. This may be the case for some teams, but not for others. It really depends on your requirements.

Now interestingly, its worth pointing out that the definition of done can change depending on the maturity of the team and the product. As an example, to help deliver a working piece of software that adds value to the business early on in the project, the team may agree that development complete, acceptance testing complete and product owner approval is enough to indicate a user story as done. However, as the product is moved to production, there may be additional criteria, such as update support documentation and user documentation. It is quite acceptable to change this based on what the team deems necessary.

The thing to note with having additional criteria for the definition of done means that the number of stories that you can complete in a sprint will drop. This is not an issue because when they are completed, the story in which they are finally completed will claim their story points. Often, management feel like the product team are not being productive because stories are not being completed within a sprint. However, the reality is, stories will get completed it just takes a little more time, that is unless the project finishes before user stories can be closed.

Conclusion

In summary, what constitutes a story as complete are a clear set of acceptance criteria, and a clear definition of done. It is important to know that each team is different and their requirements may be different to another team. Scrum is flexible and accommodating to change, so don't be afraid to revisit your definition of done either to help increase the value to the business early in the project, or to ensure quality in later stages of the project to help support of a production system.