Introduction
Scrum has been in the game for over 20 years now, but despite that many of the companies that I am visiting are still struggling to understand Scrum framework and some of the companies or individuals have just recently heard about it.
For anyone who is just beginning the scrum journey, let me quickly summarize what Scrum is about. Scrum focuses on discovering “what” is expected (e.g. the purpose) and understanding “why” something is expected. It’s opposed to “how” we should implement the requirements. Scrum is a framework where there is a space for different tactics, which can be fitted into the context and individual case. You can think in the way that Scrum takes the best practices and scales them in the best way to fit into an individual organization.
Scrum supports very simple, but yet very effective ideas, which embrace teams to regularly check in on what they are doing. This ensures they are heading in the right direction and that they are building something that people actually want. Along with checking if the output is heading in the right direction, Scrum also encourages teams to find ways to improve not only the product or the service they are building but also themselves by asking how they could do something better and faster. This is referred to in Scrum as the Inspect and Adapt cycle.
You can find more information about DevOps in the following post: DevOps: The Three Stage Conversation - People, Process, Products, which describes the basic principles of DevOps. This post will be especially helpful to those for whom DevOps is still a new concept. If you prefer a deeper view on this topic, have a look at the following guide: Quick Guide about Basic Principles of DevOps, which presents an overview of the DevOps process and practices, describing “the big picture”, while still maintaining a high level of detail.
In this post, I will address 5 different types of meetings to be held during the sprint in order to utilize the scrum values, with open communication, collaboration, and efficiency. Scrum meetings help teams to keep improving and to keep moving in a direction that will bring out the best outcome with high quality.
Ensuring specific time-boxing for sprint meetings will secure higher efficiency for the whole team and, of course, the project itself. With this cyclical process, the team will be able to achieve better communication openly and honestly. With a sprint length of one week, the time boxing for all meetings is estimated to be min 6h and max 11h. Prior to holding the first meeting, the backlog should be well refined and prioritized. This is a very important aspect, as the people who are actually going to work on the completion of backlog items should estimate how much effort it will take them to complete a particular work item. As the backlog refinement is another important topic, I will cover it separately in another future post.
[More Info]{.ion-info} If you want to know more about maintaining the backlog properly, visit the following post: Key Tips For Maintaining Good Product Backlog in Agile and Scrum. The post describes a way to efficiently organize the backlog items, allowing you to understand the requirements better and providing you with a higher level of detail on what is actually expected from the work or delivery perspective.
Sprint Planning (2-4 hours for 1-week Sprint)
This is the first Sprint meeting and should be held at the very beginning of the Sprint, with an approximate duration of 2-4 hours. The duration of the Sprint Planning meeting depends on the Sprint length, and for a 1-week sprint, it should be between 2-4 hours.
Usually, in a Sprint meeting plan, all team members are present, including the Product Owner and the Scrum Master. In this meeting, the team will take the top items from the backlog and estimate or forecast how much they will deliver in the sprint. Based on that, they will have the team’s velocity. Once the team has run a couple of sprints, they will understand the velocity of each past sprint. This is also an opportunity to strive towards improving the velocity in future sprints. This means the team will understand how many points they managed to deliver in past sprints and will try to improve that number in future sprints.
The post User stories in Agile world focuses on an important unit of Agile software development process, which is the User Story. The post also describes some basic rules and recommendations you have to follow before adding the descriptions of PBI.
Goals of the meetings:
- Agreed and verified about the PBIs that will be delivered in the sprint
- Add all the team members’ capacity, and days off
- Assigned the PBIs/User Stories to team members
- Planning individual tasks for all team members that respect the capacity for the sprint (Green)
One of the very important principles of Scrum is that the team should be committed to what they say they will complete in the sprint. This should not be changed, and the team should really try hard by any means to deliver what they have committed to deliver. To make this smooth, the teams usually use Scrum Boards, so that they can track their progress at any time.
In some of the previous posts, you can find high-level descriptions of Agile principles and the usage of some Agile tools and Agile methodology.
Stand-up meeting everyday (15 minutes)
This meeting keeps the rhythm of the team in the right place. It should be held every day, at the same time, in the same place. The entire team should be present, including the Scrum Master. As Scrum teams are self-managed, the presence of the Scrum Master is preferable, but sometimes the meeting can also take place without the Scrum Master. The role of the Scrum Master in this meeting is usually to ensure that the team stays within the time boxing, that everyone gets the chance to speak, and to remove any impediments coming in the team’s way.
Goals of the meetings:
- What they did yesterday that can help the team to successfully deliver items from Sprint Planning.
- What they are going to do today that will help the team to finish the Sprint.
- Is there any blocking point or impediment on their way?
With this meeting, the whole team will have visibility on where exactly they are in delivering the Sprint and if everything is going in the direction to be delivered on time.
Grooming (Refinement session) (0.5 to 1 hour) (1-2 times/week)
As previously mentioned, the first grooming session should be held even before starting the sprint. Preferably, this is not the only Grooming session to be held. It is usually and highly recommended to have another grooming session somewhere in the middle of the sprint.
Notes:
- Prerequisite of the meeting (backlog is prioritized)
- The meeting is time-boxed; thus, we must divide the time for all activities and finish as much as the time allows us.
- The meeting is divided into two parts (refinements 75% - estimation 25%)
- For refinement, as we go down, we spend less time on each item. For example, if the item at the top takes 10 minutes, the item below should take 5 minutes, and the one below should take 3 minutes, etc. Once we reach 75% of the time, we stop and go for estimation.
Goals of the meetings:
- Consider prioritization during the refinement, but don’t spend a long time on this activity.
- Approve or remove obsolete items (PBIs/User Stories) that are no longer needed
- Refinement for the title and the description
- Add initial or more acceptance criteria
- Add new items if necessary from the discussion
- Estimate the items
[More Info]{.ion-info} Read about basic guidelines that you need to consider when building a product backlog in the following post: Requirements (Epic, Feature, User Story), Task Size and Estimation in Agile and Scrum, and also about maintaining and refining the product backlog in Key Tips for Maintaining Good Product Backlog in Agile and Scrum.
Sprint review meeting at the end of the sprint (2-4 hours)
The Sprint review, as the title implies, is held at the very end of the sprint. In many cases, you will hear people using the term “Sprint Demo” as this is what this meeting is about. The team will show the demos of their work and exactly what they produced during the sprint.
However, one important aspect of the Sprint Review is that the team should present only the working items that they have delivered. This means the team will present or demo the work items that met the Definition of Done (DoD), meaning that this item doesn’t require any more work to complete it. It is ready to be delivered.
Goals of the meetings:
- Explain what items have been “Done” and what has not been “Done”;
- Discuss what went well during the Sprint, what problems the team ran into, and how those problems were solved
- Demonstrate the functionality built during the sprint
Retrospective meeting at the end of the sprint (1 hour)
The goal of the Sprint Retrospective meeting is to discuss openly what went well and what didn’t during the sprint, so the team can find better ways to meet the project’s goals. The team can also discuss internal processes during this meeting.
This meeting requires trust and maturity to discuss potential issues openly. It is very important for each team member to be aware of the responsibility of each individual to find solutions that could make them perform better and faster.
During the Sprint Retrospective, the team will address the following questions:
- Start doing
- Stop doing
- Continue doing
There are many VSTS extensions designed to make the work process easier. One of them is the Delivery Plans extension, which provides better cross-team visibility. Read more about it in my post Delivery Plans Extension for VSTS to learn how to manage more than one team in a much easier way.
Conclusion
All Scrum meetings are designed to help teams deliver faster and solve any possible impediments immediately. Each meeting is an opportunity to improve the process and performance significantly. This cycle of meetings should be considered in each Sprint cycle, considering the team’s previous experience.
VSTS, as an Agile tool, has capabilities supporting Scrum values in a great way, enabling strong visibility and transparency for the whole team. In the next posts, I will elaborate more about the VSTS backlog and requirements links and sizes, to get more insights about the whole idea of linking the tools with the process.
If you would like to know more about the best practices for DevOps, Continuous Integration, and Continuous Delivery, you can check out the following post: Configure CI (Continuous Integration) and CD (Continuous Delivery Pipeline).