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.