Scrum Meetings

In the last few articles, we have covered many different aspects of Scrum. In this article we are going to check out the different meetings we could have in a team executing a Scrum Project.

To Refresh – What is Scrum?

Scrum is a management framework for incremental product development using one or more cross-functional, self-organizing teams of about 6-8 people each. It provides a structure of roles, meetings, rules and artefacts. Teams are responsible for creating & adapting their own processes within this framework. Scrum uses fixed duration development cycles frequently called Sprints or Iterations which are typically 2-4 weeks in length. Scrum teams attempt to build a potentially shippable (a.k.a Property Tested) product increment at the end of each Sprint/Iteration.

What are the Different Scrum Meetings?

Scrum is a collaborative methodology where the different teams have very close interaction with one another. In each iteration or sprint, we could potentially have 4 different meetings starting with the Planning meeting and ending with the Retrospective. We will take a look at each of them in detail next.

Note: All these meetings are facilitated by the Scrum Master who by the way does not have any decision making authority in any of these meetings.

The Sprint Planning Meeting

Also called as an Iteration Planning Meeting, at the beginning of each sprint, the Product Owner and the Team hold a Sprint Planning meeting to negotiate which items from the Product Backlog they will attempt to convert into working product during the iteration. The product owner is responsible for declaring which items are the most important to the business. The team is responsible for selecting the amount of work they feel, they can implement without accruing technical debt. The team “pulls” work from the product backlog onto the spring backlog and begins work.

Real Life Trivia:  Gauging the teams available capacity in a sprint is one area where almost all scrum teams face stiff challenges especially when the product is in its initial stages or the product itself is quite complex in nature. This is the reason we used the sentence without accruing “Technical Debt” because if the team commits to build X amount of work in an iteration but actually delivers only Y amount of finished product, the difference (X-Y) becomes the teams technical debt that gets carried forward. The Scrum Master facilitates the gathering of estimates from the start of the sprint and the actuals at the end of the sprint so that the team can work towards improving their estimation. This makes the teams work output more predictable and stable.

If the product backlog hasn’t been refined to a satisfactory level, bulk of the planning meeting actually goes into doing this (Ideally a Backlog Refinement Meeting should be scheduled before we go into the Sprint Planning session). Towards the end of the planning meeting, the team will breakdown the select items into tasks and makes a final commitment to do the work.

The maximum allotted time (a.k.a Timebox) for Sprint Planning meeting is usually 2 hours per week’s duration in the Sprint. That means, for a 2 week sprint the max duration would be 4 hours.

The Daily Scrum

The Daily Scrum is like the bread & butter of this methodology. Every day preferably at the same location & time, the Scrum Team members will spend about 15 minutes reporting to one another. Each team member will quickly summarize what they did the previous day, what they plan on doing today as well as any potential impediments he/she faces.

As everybody is standing up, there will be a sense of urgency for everyone to finish their updates and return back to their desks. Most teams also maintain a sprint Task List (typically on a Scrum Board) which are tracked on a daily basis during the sprint execution.

Real Life Trivia: As the sprint development is underway, newer tasks could potentially be discovered which may be vital towards achieving the sprints delivery goals.

It is always a good idea for the product owner to attend the Daily Scrum. This can help the team get their queries clarified almost instantaneously and keep up the momentum going.

Real Life Trivia: In some organizations the Scrum Master or the Product Owner also happens to be the guy who wears the tag of “Boss” or “Manager” which often times leads to the Invisible Gun effect where everyone in the team is wary of what could be the potential implications. This actually hampers the foundation of scrum teams which are supposed to be self-managing and self-organizing. So, it would be a good idea to leave out folks with authority over the team from daily stand-ups to foster a more open & collaborative environment.

The daily scrum is intended to move away from the traditional waterfall concepts like the Status Meeting where everyone is sharing a progress update to the project manager. So, the scrum master should facilitate the team to share updates with one another rather than to him/her.

The Sprint Review Meeting

After the Sprint’s execution timebox completes, the team holds a Sprint Review Meeting to demonstrate the working product increment to the Product Owner as well as other stakeholders. This meeting is usually a live demonstration of the finished product and in some organizations also called the “Sprint Demo” or the “Show & Tell” meeting.

After the demo, the Product Owner reviews the commitments made at the Sprint Planning Meeting and declares which items he/she considers as “Done”. As unfinished work items don’t qualify as potentially shippable, there could be items that may not be considered as “Done” for ex: a new screen which is only code complete but isn’t tested thoroughly.

Real Life Trivia: The term “Done” is of crucial importance because this is one area where the product owner and team may have misunderstandings. During the iteration planning meeting, one of the focus points should be the “Definition of Done” and the Product Owner must document what he/she expects from the product to ensure that the development team clearly understands the same.

Incomplete items are returned back to the product backlog and ranked according to the product owners current/revised priorities and become potential candidates for future sprints. The Scrum Master helps the product owners and stakeholders to convert their feedback into new backlog items for prioritization.

Real Life Trivia: New scope discovery often outpaces the rate at which the team is able to deliver features in each iteration. Hence, the role of the product owner becomes very crucial towards the success of the project. The product owner is expected to evaluate the current/new scope and keep the product backlog up to date so that, whenever the next sprint starts the team will work on the top most priority items that add the most business value to the product.

The Sprint Retrospective Meeting

Each Sprint or Iteration should end with a retrospective. During this meeting the team reflects on its own processes. They inspect on their behaviour and what was done and think about actions to improvise the same for future sprints.

A good Scrum Master will try to find means to keep the meeting objective and not let it become the dreaded name calling blame game type exercise. In a mature organizations the team has psychological safety and can openly share points about mistakes made in the last sprint.

A common impediment to the outcome of a productive retro session would be the presence of people who will be doing the performance appraisal of the team. In such situations the team will move towards diverting the blame to someone else in the team instead of identifying a fruitful solution to the problem at hand.

Retrospective sessions can also expose organizational impediments. Once the team has actually listed down the impediments within their immediate influence and act on the same, the Scrum Master should expand that list and start chipping away at organizational impediments too.

Real Life Trivia: Sometimes it is easy to blame organizational impediments which the team have very little to no control and forget about areas of improvement within the teams confines. A good scrum team will list down these organizational impediments as well as things in their control to make sure the outcome is the best possible given the situations.

Backlog Refinement Meeting

As we know by now, the Product Backlog is a continuously changing list of work items that are arranged by priority. One of the key tasks of the Product Owner is to make sure this priority is up to date with respect to the company’s vision for the product so that, when an iteration/sprint starts, the team can focus on the top most priority item.

However, most product backlog items may need refinement because they could be too large or poorly understood. Teams have found it beneficial to actually spend some time each sprint to prepare the product backlog for the next sprint planning meeting. This is an optional activity that can add a lot of value (and make things better) for the scrum team but is not one of the mandatory activities. Hence this isn’t part of the initial picture chart outlining the scrum process meetings.  

During this Backlog Refinement Meeting, the team will estimate the amount of effort they may need to complete the items in the backlog as well as provide other technical information to the product owner so that he/she can decide on the priority for the items. Large or vague items are usually split, clarified and may be individually prioritized based on both business as well as technical concerns.

Real Life Trivia: Sometimes, only a small subset of the team will spend time in refining the backlog instead of the entire team to save everyone’s time.

It is a common practice to write the product backlog items in a User Story format. In this approach large/vague items are called Epic Stories and the team will work together to breakdown this epic story into smaller more manageable child stories that can be individually worked upon.

Real Life Trivia: The saying old habits die hard is very true for software development also. Most people will tend to fall back on old habits like trying to do things in waterfall way by breaking down epic stories into activities like design, development, testing etc instead of actual smaller stories that can be designed built & tested in a single sprint.

Hope you were able to understand the different scrum meetings in detail. In the next article we will review the different Scrum Artifacts like Product Backlog, Product Backlog Item etc.

Prev: Things you need to know about Scrum