What is a story that is considered done in a sprint ?
Each scrum team may have their own version of the Definition of Done (DoD) for each story as long as they agree on the common concept as a whole (from product owner, business analyst to scrum master, developers and testers.
It is essentially an achievement for the team and the individual based on the list of criteria set for the definition of done. For example, a story can be considered done when it is assigned to a software developer who develops the functionality or enhancement in the Development environment based on the description of the story and its acceptance criteria, deploys it to the Staging environment, ensures unit testing is successful and the final result will be the QA team who will validate the end to end scenario and provides a successful test result.
In another instance, the story can be also be considered done once UAT is successfully signed off.
There are other examples of what a definition of done is but the important thing is how the team works together and arrives at the DoD. It can be improvised in future to cater for certain processes but the aim is to get the team members delivery to meet a certain standard and quality.
In scrum.org, the DoD refers to releasable product increment. In a sense, that applies to the sprint itself and its goal. However, in reality and in fact many times, stories are subsets of an epic (or a module) and hence can only be releasable after a certain set of stories are completed.
However, what is important to remember is this,
- The scrum team’s common understanding of what constitutes the DoD.
- The acceptance criteria for each story must be fully understood.
- The quality of the product increment must not be compromised.
- The clarity of other non-functional requirements that may or may not have impact on the product.
I will elaborate more on each point above to provide some examples. You can also refer to the Scrum.org resource article at the end of my post below.
1. Understanding of Definition of Done (DoD)
Here, I would like to describe some points based on the definition provided by Scrum.org.
According to official Scrum, Definition of Done (DoD) is a set of criteria that must be met before a product increment can be considered complete and potentially shipped to customers. It is an agreement within the development team about what needs to be done in order to consider a product increment as “done” and ready for release. –
It should be specific, measurable, achievable, relevant, and time-bound (SMART). –
The DoD should be applied consistently across all product increments. –
The DoD helps to ensure that the product increments delivered to the customer are of high quality and meet the desired level of functionality. –
2. Acceptance criteria
- Ensure that the acceptance criteria is clear and understandable by all members of the team (e.g. developers and testers). The conditions need to be listed out so that this can be clear
- Have SMART objectives clearly defined – Specific, Measurable, Achievable, Relevant and Time-bound. You can check out some examples here.
- Specific : When writing the description and acceptance criteria, be precise and detailed if possible to avoid more change requests later.
- Measurable : The criteria and outcome should be measurable either via numbers, visualization or expected results.
- Achievable : It must not be something too vague and must be clarified by the person assigned to the story to ensure it can be developed as per expectations.
- Relevant : When reviewing the acceptance criteria, the scrum team should go through and clarify any pertinent points and clear any ambiguities.
- Time-bound : As much as possible, try to estimate the story points and time bound it to within the sprint or next sprint.
- Stakeholder involvement is very important from the get go.
- Always prioritize and sometimes re-prioritize if necessary.
- Keep the stories as small and independent scope as much as possible without jeopardizing the sprint goal.
- Use readily referenced templates or visual references such as charts and diagrams for better understanding and visualization.
To be continued in Part 2 [Stay tuned for the link]
Disclaimer: What I am sharing is purely from my point of view and experience working with various teams as a scrum master. It does not reflect anyone else’s opinion or endorses a framework.
What I present in my posts doesn’t necessarily mean that it is applicable to your work, organization and culture but I am glad if it aids you in your agile journey.
Sincerely and with many thanks for reading my articles, Jason.
References :
https://www.scrum.org/resources/blog/done-understanding-definition-done
https://medium.com/@dannysmith/the-definition-of-done-what-does-done-actually-mean-ef1e5520e153
https://www.knowledgehut.com/tutorials/scrum-tutorial/definition-of-done
