The Sixth Scrum Ceremony

When you team is ready to mark a story as done what do you do?

  • Someone just closes the story?
  • Have a team discussion?
  • Other...?
The Scrum Guide discusses the Definition of Done, but it doesn't discuss how to make sure that a completed story has met the definition of done. An additional question worth discussing is when a story is done, how does your team ensure they have completely met the acceptance criteria? The criteria that was agreed upon with the stakeholder to know when the story is complete.


 My team has found value in creating an additional Scrum ceremony to solve this problem. The scrum guide discusses the standard five Scrum ceremonies, which are required elements of Scrum. Hopefully you are not just going through the motions of those ceremonies but actually doing them well and deriving value from them. That is for a post some other day. 

The ceremony I am talking about is Story Closing. We have found great value in closing each story as a team to make sure we are in agreement that we have met the acceptance criteria and the Definition of Done. A few times we found that we missed something and were not quite done with the story. Interestingly for us, it is much less often an issue with the Definition of Done, than with missing part of the Acceptance Criteria.

When we have finished all of the tasks on a story one of us asks if we are ready for a closing ceremony. As soon as we can, we gather around to review the story and the acceptance criteria. We demonstrating to ourselves that the story is done, almost like a mini story review. When we find the story is not done we add tasks to the story and work as a team to complete them and then have another closing ceremony. 

 This helps to make sure that done means done and we avoid the notion of "done-done" and "done-done-done", etc.

 The Story Closing ceremony allows us time to make sure we are all in agreement and to catch issues earlier in the cycle. By making it a bit more formal we ensure that we do not forget and skip this important step of making sure that done means done.

 At Sprint Reviews we often have good discussions about what changes and enhancements our stakeholders would like to see, but we no longer have red faces because something we thought was done wasn't.

 How does your team solve this problem? Or is it not a problem for your team? Drop a line and let me know.

 Stay healthy, safe and agile.

Comments

Post a Comment

Popular posts from this blog

The Five Dysfunctions and Tuckman's Stages

No, this is not a post about a new band, it is about understand Scrum team growth . In my  previous post I discussed The Five Dysfunctions of a Team by Patrick Lencioni and how the dysfunctions in that book apply not only to management teams as described in the book but to Scrum teams as well. In 1965 Bruce Tuckman proposed his model of team development. While you may not be familiar with Tuckman’s name, you have probably heard of the stages of his model, forming, storming, norming and performing. Forming - The team is coming together for the first time. Team members behave independently, they are on their best behavior and very focused on themselves. To move out of this stage, team members must be willing to risk the possibility of conflict Storming - The team members are learning each others strengths and weaknesses and learning to trust each other. Some of the teams disagreements are passionate, but also can tend to lean toward personal attacks as opposed to healthy confl
Read more

How many dysfunctions does your Scrum team exhibit?

Image
If you say your team does not exhibit any dysfunctions I have to ask you to revisit your thoughts again as that is so very highly unlikely. Most if not all teams exhibit some dysfunction some of the time, if not all of the time.  Merriam Webster defines dysfunction as  impaired or abnormal functioning or abnormal or unhealthy interpersonal behavior or interaction within a group I think both of those definitions work well with regards to a Scrum team. In Patrick Lencioni's book The Five Dysfunctions of a Team he tells a tale about the five dysfunctions that a team typically struggles with followed by a discussion of how to address them. As a scrum master it is well worth the time to read it. As far as I know the author was focusing on management teams when he wrote it, but without very much tweaking, all the same dysfunctions and corrective actions apply to a Scrum team as well.  The five dysfunctions are laid out in a pyramid. The reason for the pyramid is that
Read more

Feedback - Skills Relevant in the Torah and Today

There is a story in the Old Testament known as the Waters of Strife . It occurs when the Jews were wandering in the desert. They complain to Moses that there was no water and that they were going to die. Moses prays to G-d, the response is to talk to a rock and tell it to give water. Instead of talking to the rock, Moses hits the rock and water comes out. Aaron was punished after this incident. Reading the text in the original Hebrew, Aaron wasn't given any instructions other than to accompany Moses, which he did. What did Aaron do wrong? Why was he punished? At this point if you are still with me, you are probably wondering what this has to do with agility or Scrum. It was Rabbi Yehuda Meyers that gave me the answer to both of those questions, both what Aaron did wrong and what does this have to do with Scrum. Aaron's mistake was a simple and a common one, unfortunately one made on many Scrum teams.  First, a bit of background is needed. This event occurs right after Mo
Read more