A couple months ago I heard one of our team members say that “Scrum wastes a lot of time on meetings” and that “most of them are not even necessary”. If we look at this idea from the developer’s point of view it’s understandable, being part of a Scrum ceremony, listening to everyone when sometimes the topic has nothing to do with her role or feature, might seem boring. But did you know that a single team member can screw up an entire project (even without noticing) by not following a scrum process correctly?
According to the methodology, there are some events in which the developer has to participate, but there are other equally important tasks that the developer needs to do to help with the larger development process. In this post, I’d like to do a quick review of the five ceremonies of Scrum to help us reconsider their value. So, first things first, let’s begin with…
Definition of Done
Contributing to the creation of the definition of done is important for a successful development process, since having an unclear definition might cause misunderstandings, eg: miscalculating the remaining work for each feature, incorrectly estimating the features at the beginning of the sprint, or not being clear on if a story should be delivered within a sprint or not.
The team shouldn’t make the mistake of leaving a single person (usually the Scrum Master) to write down the definition of done. Making a good one is a shared responsibility between all the team members and the Product Owner.
To accomplish this step all the team members should share their opinion about what should or shouldn’t be part of the process of delivering a feature based on their experience and their team dynamics. For instance, if their experience says that they should do TDD or that the team works better with small pairing sessions instead of pull requests for code review, they have to share their thoughts to make a Definition of Done that fits their specific needs.
On one occasion, on the last day of a sprint, one of the team members finished a feature he had been working throughout the sprint. He could not deploy it to the staging server since on that day there was nobody that could review his code. During the daily stand up he didn’t report it as an impediment because, from his perspective, the development process had ended when the coding phase had finished. At the end of the day, when the Product Owner checked the work from a local computer, and in spite of the fact that the feature was technically working, he considered it to be useless because he wasn’t able to show it to any stakeholder for testing. When I was asked for my opinion (and observing it from an external point of view) it was more than obvious that there was a failure in the definition of Done. For the Product Owner, it was required that a feature was on staging to marked as complete. Unfortunately the development team never had it clear.
After talking about the situation, the team stipulated in the definition of done that in the case that a code review couldn’t be performed, the developer would have to do a code refactor by himself. But for a feature to be considered as completed, it must have been deployed to staging.
After all, there is no “correct” or “incorrect” definition of done, but there is a correct way to go about defining it. Collaboration is necessary.
Backlog Grooming Meeting
In this ceremony, the developer will clarify all the stories in the backlog and should accept or reject them as a part of the next sprint.
- There can be no trace of doubt afterwards: The developer has to remember that the stories presented in the backlog grooming are items that she will be working on sooner or later. It’s very important to clear all doubts and vague concepts no matter what, and be aware that there are no stupid questions if they help to fully understand the stories.
- Technical challenges: When the developer is asking questions, it is also important to think about their implementation. For instance, the knowledge that she has about certain tools or programming languages. Sometimes, there are technical limitations that won’t allow for the development of a story as it was designed initially.
- Take a look at the current code base: It might happen that the Product Owner asks for a feature that sounds easy to implement, but when the code is analyzed the realization comes that it will be much more complicated than originally thought, because of the current code base. If a development team keeps the big picture in mind, they will have a better idea of how to implement each feature and be able to ask smart questions based on that. It is easy to fall for this when new team members enter a project, or when the team starts working on a part of the application that hasn’t been touched for a while.
- The team has the control: The team needs to remember that they can reject the stories if they are not well described or if they can’t be developed with as requested. Even when the story is simple to the naked eye, it’s always better to write at least one acceptance criteria.
Sprint Planning Meeting
As we’ve already seen, it’s important to answer any questions that the team may have about the stories. Once every question has been resolved, the team will proceed to estimate the stories. Regardless of the estimation method, there are some points that every team has to consider for a proper estimation.
- Make conscious estimations: It is always a headache for the development team to make a precise estimation for the stories, however it is important to try our best to avoid over or underestimations. That’s because, down the road, the team will use those stories for reference purposes, and if they are not even close to reality, future estimations will be affected.
- Keep in mind the Definition of Done: once the team is doing the sprint commitment, it’s easy to forget about the definition of done. It is essential to always keep in mind the whole set of steps that make up for it to avoid over-commitments.
- Looking at the history: It is necessary to consider previous sprints as a reference for the incoming commitment. A useful rule, do not make a commitment of more than what has been delivered on the previous 3 sprints.
The daily standup meeting might be the most important ceremony in Scrum since it’s all about keeping the team coordinated between them. This is the moment when the team can share to each other about the progress made, impediments, achievements or any relevant situation that the team needs to be aware of.
- Believe that somebody else can help: it is very common that one of the team members can’t realize that he has a blocker. This is where the Scrum Master comes to the rescue. It is important to be humble here and remember that the Scrum master is the one that is overseeing the process and he can easily discover when somebody needs help.
- One step at a time: another good practice here is to use this event as a “commitments ceremony” to be able to determine if a story will require support from the Scrum Master. If the team members make small commitments on a daily basis, it is easier to remain focused on the sprint goal.
At Tangosource, instead of having a meeting for this at the end of each sprint, we have daily reviews done by the Product Owner.
We have a golden rule when testing and reviewing: “Go by the acceptance criteria”. It sounds obvious, but it’s easy to forget sometimes. Before delivering a story, we make sure that we have double checked that every criteria has passed. By following this golden rule, the development team ensures that the story is achieving the goals that the Product Owner wanted, lessening the possibility of having a rejected story.
In Scrum, each ceremony has its own importance, and this also applies to the sprint’s retrospective meeting. Once the team has finished the sprint, it’s time to talk about what just happened. There are many ways to do this, but the one we have found to be very useful is answering three simple questions:
- What should we continue doing?
- What should we stop doing?
- Are there any ideas to improve as a team?
A common mistake is to skip this ceremony under the excuse that is not as important as the other ones, and that the team can use that time for a more meaningful activity. But remember, if something went wrong during the previous sprint and the team didn’t have a discussion about it, chances are it will happen again soon. I saw one example of this when a team had had a couple of sprints without delivering much value. From the Scrum Master’s perspective, the obvious reason was because the Product Owner was adding features at the middle of the sprint. Because of the rush, the team had been skipping the retrospective for 3 weeks in a row under the excuse that there were urgent bugs to deliver. When I was invited to analyze the situation, I gathered all the team members to talk about the project’s issues, and one team member wrote down that the technical debt of the project was making it difficult to incorporate new features. By talking about that, the team realized that they should have focused their effort on solving that situation first, and that once they had solved it, adding features mid sprint was not going to be a problem anymore.
After a couple of sprints I took a look at the project again, and it turned out that they were delivering features and that the sprint disruptions reduced a lot. We can see here that the Sprint Retrospective is a valuable ceremony for the Scrum process, and that if the team talks about the issues that they are having, they can improve their performance and the value delivered each sprint.
It is true that the Scrum Master is the guardian of the methodology, and that he or she should lead the process, but a successful project involves more than excellent work from the Scrum Master and well defined requirements. Scrum is a methodology that helps the team to succeed in the software development process, but it requires that every team member is committed to support it.
Thanks to my friend and co-worker Jonatan Juarez who contributed on the creation of this post.