1. Seven Dimensions For Agile Product Development....................................................................................

4
The Seven Product Dimensions Model........................................................................................................4
Illustrating The Seven Dimensions With A User Story.................................................................................6
Tips to for successful user stories................................................................................................................7
1. Understanding User Stories..........................................................................................................................7
a. What is a user story?................................................................................................................................7
Story ID.......................................................................................................................................................12
Story Title....................................................................................................................................................12
Story Rank...................................................................................................................................................13
Story Description........................................................................................................................................13
Story Points.................................................................................................................................................13
Story State..................................................................................................................................................13
Blocked or Impeded Status.........................................................................................................................14
Blocked Reason...........................................................................................................................................14
Parent.........................................................................................................................................................14
Release Information....................................................................................................................................15
Sprint Information......................................................................................................................................15
Owner.........................................................................................................................................................15
Assigned to................................................................................................................................................. 15
Project Code............................................................................................................................................... 15
Child Story.................................................................................................................................................. 15
Task(s).........................................................................................................................................................16
Successor(s)................................................................................................................................................16
Predecessor(s)............................................................................................................................................16
Discussion(s)...............................................................................................................................................16
Defect(s).....................................................................................................................................................17
Test Case(s).................................................................................................................................................17
Attachment(s).............................................................................................................................................17
Tag(s).......................................................................................................................................................... 17
 User Story.......................................................................................................................................... 18
 Non- User Story..................................................................................................................................18
 Spikes.................................................................................................................................................18
1. What is Agile Estimation ?.....................................................................................................................20
How Agile estimation is different?.................................................................................................................20
Understanding Story Points...........................................................................................................................22
Agile Estimation Techniques for user story...................................................................................................27
2. What is Daily Scrum Call or Stand-up Meeting...................................................................................29
Basic Rules of Daily Scrum Call....................................................................................................................29
 Daily Scrum Call – Good Practices and what to avoid.................................................................................30
Good Practices............................................................................................................................................30
Avoid...........................................................................................................................................................31
Participants of Daily Scrum Call or Daily Stand up Meeting........................................................................31
Scrum Roles and responsibility during daily scrum call or daily stand up meeting.....................................32
Purpose of daily scrum call or Daily Stand up Meeting...............................................................................34
Why Standing up ?......................................................................................................................................34
Scrum Call Approach for Distributed and Co-located team ?......................................................................35
Outcome of Daily Scrum Call......................................................................................................................36
Challenges of Daily Scrum Call....................................................................................................................37
3. Why do we need Prioritization ?............................................................................................................38
What is Product backlog Prioritization ?.........................................................................................................39
What to Consider during prioritizing agile work item?....................................................................................40
Scrum team members role during Prioritization?...........................................................................................43
Product Owner........................................................................................................................................... 43
Scrum Master............................................................................................................................................. 43
Development Team....................................................................................................................................43
Facilitate..................................................................................................................................................... 43
When to prioritize stories in Backlog?.............................................................................................................44
Backlog items in different state to prioritize...................................................................................................44
Techniques to Prioritize Product Backlog Items..............................................................................................44
4. What is Product Backlog Grooming........................................................................................................47
Why we groom stories in backlog?.................................................................................................................47
Who is responsible for backlog Grooming?.....................................................................................................48
Product Owner...............................................................................................................................................48
Scrum Master................................................................................................................................................. 48
Development Team........................................................................................................................................49
Other Memeber..............................................................................................................................................49
When a Team should conduct Backlog Grooming?.........................................................................................49
Details Insight of Backlog Grooming...............................................................................................................51
Metrics to measure backlog health or grooming state...................................................................................53
Backlog Health............................................................................................................................................53
Grooming efficiency....................................................................................................................................54
Post Grooming Activities.................................................................................................................................55
Capacity Planning................................................................................................................................................57
5. What is Capacity Planning......................................................................................................................57
How to do Capacity Planning (in Hours)..........................................................................................................57
So The Final Capacity for this Team for Sprint 2 is 318.32 Hours................................................................61
 Step 1..........................................................................................................................................................61
Step 2..........................................................................................................................................................61
Step 3..........................................................................................................................................................62
Step 4..........................................................................................................................................................62
Step 5..........................................................................................................................................................62
Step 6..........................................................................................................................................................62
Step 7..........................................................................................................................................................62
When we should do Capacity Planning...........................................................................................................63
Benefits of Capacity Planning..........................................................................................................................63
6. What is Sprint Planning......................................................................................................................64
Who Should Participate in Sprint Planning Meeting...................................................................................64
Scrum Master Responsibility for Sprint Planning Meeting..........................................................................64
Development Team Responsibility for Sprint Planning Meeting.................................................................64
Product Owner Responsibility for Sprint Planning Meeting........................................................................65
Prerequisite of effective Sprint Planning Meeting......................................................................................66
How much time should Sprint Planning Meeting take................................................................................67
Step by step walk through of Sprint Planning Meeting...............................................................................69
Expected deliverable of Sprint Planning Meeting.......................................................................................74
Summary report of Sprint Planning............................................................................................................75
Benefits of Sprint Planning Meeting...........................................................................................................77
7. What is Sprint Review Meeting..........................................................................................................79
Participants of Sprint Review Meeting........................................................................................................80
Time Box of Sprint Review Meeting............................................................................................................81
How Sprint Review Meeting Works............................................................................................................81
Starting the Meeting – Welcome, Introduction & Set the Context Ready....................................................82
Highlight the scope of Demonstration...........................................................................................................83
Demonstrate the new functional Increments................................................................................................84
Discuss Future Sprint Scope...........................................................................................................................84
Identify New Backlog Item.............................................................................................................................85
Re-Prioritize Backlog Item..............................................................................................................................85
Conclude the Meeting....................................................................................................................................85
Potential Outcome of Sprint Review Meeting............................................................................................85
Post Sprint Review Meeting Activity...........................................................................................................86
8. What is Sprint Retrospective Meeting................................................................................................87
Participants Sprint Retrospective Meeting.................................................................................................87
Duration of Sprint Retrospective Meeting..................................................................................................88
How to run the Sprint Retrospective Meeting............................................................................................88
Tools you can use to conduct Sprint Retrospective Meeting......................................................................98
 Outcomes of Sprint Retrospective Meeting..............................................................................................104
After Sprint Retrospective Meeting activity..............................................................................................104
Important Notes.......................................................................................................................................105

Agile WoW – Scrum Basics

1. Seven Dimensions For Agile Product Development

A lot of factors go into product development. Use the Seven Product Dimensions model to keep them straight
and your stakeholders accommodated.

The Seven Product Dimensions Model

To simplify product development planning, Agile Product coach Ellen Gottesdiener suggested seven major
factors to be checked whenever there is a need to improve the product, whether creating an additional
feature or changing/improving an existent. This is how the 7 Product Dimensions framework came to be.
In this article, I will describe every point developed by Ellen. I’ll add some observations and useful tips
collected when we applied this framework in different projects. Finally, I’ll include some adaptations made in
order to optimize the framework and attend to product constant scenarios.
 “7 Product Dimensions” by EBG Consulting is licensed under CC BY-NC-ND
Users
Users are any persona that will interact with product or feature. This can be a human or another integration
system. Examples include a bank or shop customer, supply or financial company sector employees, or another
piece of software connected to your product.
Interface
The Interface is how a User will interact with the product or feature. This can take the form of a webpage,
mobile app, desktop system screen, or API endpoint, to name a few examples. Take care not to confuse this
with the Environment, which I describe later in this article.
Action
The Action dimension describes what the product or feature will do. It describes how your product provides
benefits and new capabilities for your users. To keep every action distinguishable from others in your design,
you should be able to describe each one with a separate verb. Examples: Add New Client, Start Billing Process,
Start Payment Process, etc.
Data
The Data dimension refers to the information about product or a feature’s input and output data. You can
describe this as useful tips and messages for the user’s benefit. Here are some examples:
 Input Data can be a user’s full name, company name, ID number, zip code, address, or other contact
information.
 Output Data can be a user’s account balance, bill processing date, payment deposit date, and so on.
Control (Business Rules)
The Control dimension refers to all rules the developer must follow for product or a feature. This is the place to
describe all data and regulations that will restrict any aspect of your product. As part of your development
plan, you should outline these controls in as much detail as possible. Be sure to include any relevant laws and
regulations as they pertain to your industry and location. This is not to be confused with Quality Attributes,
described later.
As an example: when collecting identifying information from clients such as a social security number, each
client can only have one at a given time.
Environment
The product’s Environment contains the technology and infrastructure requirements needed by product or
feature to work correctly. When we’re in the process of designing a product or planning a major update, this is
the space to outline non-functional requirements. These could be the software architecture for
implementation, cloud clusters, web hosts, and so on. When you talk about adding a new feature or updating
an existent one, this is where you’ll see the change performed. For example, we change only a page on an
entire website, or only one screen in a mobile app.
This is similar Interface but still fundamentally different. Interface refers to how the user interacts with the
product. Environment refers to how a given product or feature interacts with other features, platforms, or
integrations.
Quality Attribute (QA)
Th Quality Attribute or QA dimension refers to any required quality controls. Any Controls described earlier
must have a corresponding QA. This differs from the Control dimension because Controls are set by an outside
force, while QA is established by the developers.
As an example: Controls dictate no user can have more than one SSN. Therefore, the software cannot support
the input of more than one SSN for a single client.
Illustrating The Seven Dimensions With A User Story
To make sure your agile teams understand what they need to deliver, it helps to write a user story containing
all the relevant requirements. Here is a user story sample using the seven dimensions framework as a guide.
Here I point out every dimension, marking how it can be placed and correctly organized. For this sample, I use
the scenario of a simple addition of a customer’s dependent on a bank account, providing the dependent
access to the existing account dashboard. Let’s see how this works:

Tips to for successful user stories

Here are some tips to for more successful user stories:

 During the refinement and story writing, the team needs to see that all dimension elements are
sufficiently described.
 Keep user stories brief, ideally describing one task at a time. If a user story grows to be longer than
you expect, this is a good sign that you should split this in two or more stories. Remember: the story
will be divided into tasks at the sprint planning ceremony.
 A good way to extract stakeholder information and establish your seven product dimensions is to give
them a form fill out. Ask questions like “What will this feature do?” (Action), “Who will use this
feature?” (User),” How the users will interact with this feature?” (Interface),” Where we need to
implement it?” (Environment).

I hope this helps you to discover a simple and efficient way to describe what your team needs to establish your
first feature and products requirements and maintain a high level of evolution. Like everything in agile, this
framework is simple to understand but can be hard to handle. Practice this and adapt to your daily life. But
remember: The gains and achievements proposed in a usage of framework is increased the more you stay on
standard.
 1. Understanding User Stories
a. What is a user story?
In Agile Software development, the execution level requirement or functionality is terms as user story. A user
story can be of one or more sentences. The requirement (details contents) in the user story needs to be
sufficient so that
1. A developer can start and finish his development.
2. A tester and test the developed code to check if it is meeting the required functionality.
3. Product owner/ BA / Stake holder can verify the desired functionality to accept the story completion.
Each story must fulfil a requirement with a very specific goal or benefit, it’s always advisable to break any store
to smaller stories, if it has more than one goal.
Requirement of a story must be of a complete functionality, means upon completion of development, testing
and acceptance, the code should be deploy-able, or park for future release. In other word each user story
should be potentially ship-able.
Size of a user story is measured in story points (Refer our section Estimation Techniques), to provide a business
value or complexity.

Structure of a user story?

A good user-story contains four major
segments to describe the requirements
and its testing scenarios.
1. Role
2. Goal
3. Benefit
4. Acceptance Criteria
A typical template of a user story is like
As a <Role> I want <Goal> so that
<Benefit / Expected outcome>.
The Acceptance criteria is very crucial for
a user story to use in unit testing, QA
and story acceptance by product owner
or Stake holders.
Understanding the 3Cs.
A well structured user story should have
three sections
1. Card
A one to two liner text to written as an
identifier of the user story. This can be
written as “As a — I want — So that” or
a plain text. this text usually printed on
the story cards, that is use in a story
board. Many ALM tools have a text field
named Title to capture this information.
2. Conversation
This the area where the details
description of the user story goes. This
can be start with “As a — I want — So
that”. followed by details requirement. A
Detail requirement can have Screen
shots , ware frames, external links etc to
elaborate the requirement better.
3. Confirmation.
This is the are of Acceptance criteria,
most ALM tools provide a section to
capture the acceptance criteria, if not
provided, you can write your acceptance
criteria at the bottom of your description
with a heading “Acceptance Criteria”
A typical template of a user story is like
As a <Role> I want <Goal> so that
<Benefit / Expected outcome>.
The Acceptance criteria is very crucial for
a user story to use in unit testing, QA
and story acceptance by product owner
or Stake holders.

CHARACTERISTICS OF A USER STORY

A well-formed user story needs to meet
the following characteristics of bill
Wake’s INVEST acronym
 I ndependent
 N egotiable
 V aluable
 E stimable
 S mall
 T estable
Refer the below diagram to read more
about the each characteristic
Example 1 Example 2
As an online visitor I want to add As an online visitor I want to add products in my shopping cart
products in my shopping cart so that I so that I can purchase multiple products at one go.
can purchase multiple products at one
go. ACCEPTANCE CRITERIA [ELABORATED]

ACCEPTANCE CRITERIA [ABSTRACT]  1.Given my Shopping cart is empty

Products can be added to the cart When I add a product to my cart
Then my shopping cart should contain 1 quantity of the
Products can be removed from the cart. added product
 Given my Shopping cart contain 1 product
Shopping cart will be empty initially
When I add the same product to my cart
Shopping cart will be empty after Then my shopping cart should contain 2 quantity of the
purchase product, and I can see a warning the product has more
than one quantity.
Products can be added with multiple  Given my Shopping cart contain 1 or more product
quantities in the cart When I click on delete button inside cart page for any
Shopping cart will show the total specific product
product breakdown quantity and cost Then my shopping cart should remove the deleted
with grand total product and show the remaining product in the cart
 Given Shopping cart contain one or more product
When click on confirm order on cart page
Then My shopping cart should go empty after
successful order
 Given shopping cart contain one or more products
When Open Cart page
Then It Should show all the products break down with
its selected quantity and cost and appropriate totals of
cost and quantity
 Given shopping cart contain one or more products in
Cart page
When change the quantity of any product Then the
product’s cost should be updated and subtotals of
quantity and cost should change accordingly
 Attachments:
 Wire frame of Cart page is attached.
Associations of user story
In Agile software development, we understood what is story and its structure, now we will learn the associated
members of a story in Agile life cycle. There are two main type of association, One to One and One to many, as
below.
ONE TO ONE RELATION WITH USER STORY AND ONE TO MANY RELATIONS WITH USER STORY AND
ASSOCIATED INFORMATION ASSOCIATED INFORMATION (OPTIONAL)

Story ID Child Story

A unique identifier of the user story. traditionally Few Organization or practices create sub stories
the number used to be like Epic or child stories under one user story, we
Number.Featurenumber.StoryNumber (e.g. personally advice map stories with feature as
1.3.1, 1.3.2, 1.3.5, 1.4.1 etc). how ever many parent for better mapping and tracking.
ALM tools like Jira, Rally generate the number
automatically on creation of new user story.
those number can be sequential incremental
number for the organization, or can be
sequential number prefixed by alphanumerical
value to represent groups, projects etc (e.g.
ABC123, ABC124, FIN245 etc)

Story Title Task(s)

An one liner sentence to represent the whole Tasks are the bottom most layer in user story
user story, for easy reference and discussion. A hierarchy, and always child of user story. You
meaningful crisp text to symbolize the can create smaller tasks under each user story
requirement. A title for the user story mentioned to estimate the efforts in hours based on the
as example on above section could be “Adding task assigned to resource skill level. example of
product to cart” tasks are

Development, Database Design, UI

Design, Testing, ….

Remember the effort estimation on tasks are

man hours, it has no direct relation with story
points

Story Rank Successor(s)

A number to represent the priority of the story in Successors are the dependent story(ies) linked to
backlog, the lowest number appears at the top of your story. The successor story(ies) can only start its
the backlog. to pick for grooming/planning etc. development once your story is complete.
Product Owner or Business Analyst or some time
for example
stake holder takes the responsibility to prioritize
the backlog by rearranging the rank according to Your story : Import Test data for Online purchase
the priority of execution. functionality

Successor story : Online Purchase functionality

enable add product to cart

Story Description Predecessor(s)

This is the section where the details of the Predecessors are just opposite of successors, this is
requirement get captured, Its consist of Role, also part of story dependency. You can only start
Goal, Benefit, Acceptance Criteria, attachments, working on your story once the predecessor
as mentioned under “structure of user story” story(ies) is completed.
section. This section get changes to mature up
the requirement by product owner or BA or for example
Stakeholders, The section is advisable not to
Your story: Online Purchase functionality enable add
change after the story is groomed and estimated.
product to cart

Successor story: Import Test data for Online

purchase functionality
Story Points Discussion(s)
Story points are the measurement unit, to Discussions or threads of comments on each story
represent the size of a user story in terms of between Team Members, Stake holders, External
business value or complexity. will discuss on team or dependent team. to capture and keep a
details about story point in Estimation and note on discussions happened during the
planning section. The possible values should different stages of a story.
1,2,3,5,8,13,21,… in fibonacci series, This is also
called as relative sizing.

Story State Defect(s)

In the life cycle of a user story, it goes through You can map one or many defects to each story to
mane stages from its initiation till deployed to keep a track of defects raised by the testers during
production or ready for deployment. The stages testing or verification stage, optionally you can
are not fixed it can be customized based on provide option to mark priority and severity of
organization need. the basic flow is shown as defects, with status like Open / Resolved / canceled
below etc.

The Good example of workflows for the stages of

User stories are also available as below which
break down the stages in smaller and better
track able units

Blocked or Impeded Status Test Case(s)

The Status of the user story to mark it as blocked You can also create and map one or more test cases
or impeded and causing delaying its movement to your story
in its life cycle.

The possible values are [Yes / No ] or [True /

False ] or [Blocked / Not Blocked]

majority of the time a story get blocked during

its in-progress stage
Blocked Reason Attachment(s)
Description with the reason for the blockage if Product Owner or Stake holders or BA or any one
any story is blocked or impeded, possible can provide attachments to enhance the
examples are requirement, also testers can attach test results as a
proof of testing passed or fail status.
 Cross functional team has not completed
their user story marked as our story’s
Predecessor
 Task assigned to UX, has not yet started
working, delaying dev work
 Test data not available to do a unit testing

Parent Tag(s)
Agile User stories need to be well organized to You can map or add one or more tags to your
track the product increment on each level of stories, for customize your reports or filtering the
senior management or portfolio, Each user story stories on your custom category
can be a child of a feature.

Many practices create sub user story by making

another user story as parent, which we advice to
avoid if possible.

Will learn more about User story and its

hierarchy, later on this page.

Release Information
This information contain the release number its
is planned for, Its an optional information, can be
added at any stages of its life cycle.

Sprint Information
This information contain the Sprint or
iteration number its is planned for, The scrum
Master updates the information as soon as the
story was committed for a sprint in sprint
planning meeting.

Owner
Information of the person who created the user
story, or currently owning the user story. he is
the person responsible for accepting the user
story.

Assigned to
Usually tasks are assigned to developer or tester,
but many practices do not use task. They keep on
changing the assigned-to information with the
team member’s name to marking who is
currently working on the user story, The
 Developer , or the tester, or the product owner
for verification and acceptance.

Project Code
Optional value to map user stories with some
project code or cost centre for other
management purpose.

Who can write or update user story?

Product Owner is primarily responsible of the contents of user story. Some places the Business Analyst also get
involved to write and take the responsibility of user story contents. Team members can help product owner or
BA to write user stories, but as product owner or BA understand the business requirements and acceptance
criteria better than any other team member its always a good idea to leave this responsibility with product
owner or Business Analyst.
Once Initial Draft is created, Product Owner or BA can enhance the requirement from the input from Team
member or external resource, captured during Grooming.
How ever there are instances of creating Spikes ( Will discuss about spike later in this page), Developers,
Testers, UX team member etc can write those special types of user stories
When user story can be written or updated
User Story can be written during any time, however the story contents get freezes once its is groomed and
estimated.
In case of big change in requirement introduced for a story that is already groomed and estimated, The story
needs to move back to a state for re-grooming and estimation along with updated requirement.
In case of change in requirement introduced for a story that is already committed for a sprint and the sprint is
already started, The Scrum Master needs to manage the situation by checking the size of the change and time
left on that sprint, resource availability, capacity of the team to take additional changes, possibilities of getting
approval from Product Owner to dropping any low priority story from current sprint scope. After All delivering
business value on time is the primary responsibility of a scrum team. The Team can mutually decide along with
Product Owner’s approval to drop the story from that sprint and plan for next sprint, its all depend upon how
urgent the changes needed by the product owner.

Hierarchy of user story

In an Organization structuring and mapping the user story with its parents starting from Strategic investment
till task as its child is very important to Plan, Execute and Manage the business development. The below
pictorial diagram explain the user story hierarchy and its position.
Here we explained 5 major layers.
1. Theme or strategic Investment level which is the biggest umbrella or top most layer in the tree, and mostly
takes years to complete.
2. Under Theme it has Initiatives or Epics, which is the second largest item in the hierarchy
3. and under Epics it has features, which is the immediate parents to a user story, and takes weeks, sometime
even months
4. User stories are child of feature and each story takes couple of days to complete
5. the bottom most layer placed under user story are the task layer. each user story can have multiple task
requirements, and which usually takes few hours to complete
Theme, Epics and features are the portfolio level requirements. Story and Tasks are Sprint level / or execution
level requirements.
Please Note that few organizational practices have concept of sub story where they create story under story.
We strongly suggest to create features if there is any thing bigger than story and map it accordingly.
Types of user story
User Stories are generally of three types,
1. User Story
2. Non User Story
3. Spike
Details of these three types are explained below.
User Story Non- User Story Spikes
This type of user story we create User Story of type Spike is also
This is traditionally used to work on some technical activity knowing and discovery story.
throughout the Agile life cycle to support a upcoming story of which we use to do all our
and details of user story and business functionality. we use Research and Analysis work, it
characteristics are explained in this story types to create work does not provide any Business
detail above. user story is deploy- like, database migration, backup value and not deploy-able,
able and holds business value, activity, configuring test however as per acceptance
contain a estimated story point environment etc. This story does criteria a analysis /research
which gets credited to the team not contribute any direct value to outcome document may be
upon completion business but provide the deliverable.
prerequisites to work on real
value addition story.

Keeping a story points to zero or

to some value and contribute to
teams velocity is depend upon org
level decisions. as this work also
needs some efforts from the team
member, including this story
during planned capacity mapping
is always better approach.

Sometimes a Defects or Bug become bigger and required a new development. In those cases, we create a
user story targeting fixing the issues, with an agreement from Product Owner.
 1. What is Agile Estimation ?
(Scope of our this article to cover estimating user story)

We need estimation to plan our software development, in agile we do estimation in little different way than
traditional effort estimation, its easy, interesting and yes effective too.
In Agile Estimation we can estimate at its different hierarchy item (read about story hierarchy), in this article
we are focusing on estimating user stories and its tasks.
Traditionally we use to estimate efforts to develop a functionality, where in agile we estimate Business values
or Complexity of a user story level. And estimate efforts in Task level. The unit of estimating user story for its
value or complexity is story points, and the unit of estimating a task for its effort is Hours.
We usually relate T-Shirt sizing with Story sizing to mark the relative difference between user story size, e.g.,
Extra Small , Small, Medium, Large, Extra Large etc, We will discuss about story points in details, later in this
article.
The below diagram will help you understand story level estimation and Task level estimation.

Task estimations are not always followed, Many Agile practices run their execution (sprint or iteration) with
only Story points. Tasks are used for better planning and tracking.

How Agile estimation is different?

How estimation of a user story is different than traditional effort estimation, Traditional Estimation Vs Agile
Estimation
The table below highlights the major difference between

Traditional Estimation Agile Estimation

Primarily estimation on tasks takes place to get the Estimate the size of story for its value and
timeline of the project. complexity, task estimation is secondary.
Estimate to get the timeline to complete the entire Estimate to plan how much business value we can
product deliver in a single sprint or iteration duration
(typically 2 to 3 weeks)
We estimate development, Testing and other effort Estimate the size of a story keeping in mind, its
separately for any functionality development, testing, or any other activity to
complete the functionality. However if required, we
can estimate different tasks for independent
resource specific efforts.
We estimate absolute values in Hours or Days We estimate Relative sizing, learn more about
relative sizing in our next section of understanding
story point.
 Estimate Before the development start Estimate between the development for upcoming
Stories of future iteration, by applying lessons
learned from past sprints
Estimates to create Plan of schedule, and the Estimates to Identify Value, and the development is
development is plan driven value driven
Estimates of absolute number of time, have high Estimates to Identify Value in a range in Fibonacci
chances to miss the estimate. number, have very less chances to deviate from the
estimated business value.
Panels of technical Experts, Architects and other The Agile Team, mainly Developers and Testers do
member involves to estimate. the estimation collaboratively, with presence of
Product owner or business analyst & Scrum Master.
The Team may seeks input from external Technical
or functional experts, but the estimation always own
by the team.

Understanding Story Points

Influencing Factors of Story Point :
Story Points are the measurement unit to estimate the size of a user story, on the basis of its

1. Business Value
2. Complexity
3. Risks
4. Dependencies
5. Amount of work
Story Point in Fibonacci Series:
To Estimate the size or the story point, we map a numeric value, it does not matter what are the values, what
is important is the relative deference.
Three stories having story point 1,2 and 3 is equivalent to having the story point as 10,20 and 30. however the
industry standard and to keep the practice uniform with in, team, organization, or even in the Agile world we
use the points in Fibonacci series i,e,. 1,2,3,5,8,13,21,…
Fibonacci series number have relative difference with each other to give a virtual difference on your estimation
Where story point 1 means: very easy development with no risk, complexity, dependencies and add “nice to
have” business value
Where story point 13 means : significant amount of complexity, possibilities of risk or dependencies and High
business value.
Any story appears to more than 13 points, we strongly recommend to break the story in smaller stories.

Uncertainty of Higher story point :

We always try break the story into smaller story for better estimation and visibility of its Risk, dependencies
and technical aspects. But we need to keep in mind each story has to be potentially ship-able. We should not
break a story on the basis of its task like Development in one story and testing in one story. Breaking a story
means splitting of an expected functionality by two independent smaller functionality.
Higher the points means its increase the uncertainty of its completion in time, because it has bigger risk,
dependencies, and other unknown facts.
Story Points Vs T-Shirt Sizing :
During Estimation, we need to think about all its aspects , Complexity, Business value , Risk, Dependency,
Amount of work in development and testing etc, and take a judgement of its overall size to assign a story
point.
 Its may be sounding complicated, but once you will started doing it, you will find its a fun and exciting exercise
to do an estimation.
To correlate your imagination to assign a story points of a user story, categorize the size bucket as T-Shirt size
and map a story point from the Fibonacci series with that. Refer the picture for that mapping will help you
understand how you can estimate a story point with a user story.

Relative Sizing :
As mentioned earlier, we do a relative sizing to bucket the user story with Story point, why relative sizing is
easy, Refer the Picture.
From this picture, its very hard to measure the difference between the amount of water each container can
contain, but its very easy to measure which container can contain more water and which container can contain
less, that’s relative difference in size, that is what we do to measure story points.

Lets elaborate the above concept further :

From the picture below, lets assume we have four stories to estimate it’s story points, Keeping the above
theory in mind we can estimate the story point like this as mentioned in the picture.
The wine glass we know is the smallest here, but there can be smaller container than this like tea cup, so lets
give it small not extra small, from our map we know small is Story point 3.
On a similar fashion we estimate the glass as 5, water jar as 8 and aquarium as 13. Yes 13 not 21 or more
because we know there can be many larger container from this.

Few points on Story Point:

 Estimating a story point needs the estimator to have depth knowledge of the domain, product, technology,
potential risks , dependencies etc. will talk about the techniques to estimate a story point later in this article
 Don’t Relate Story Point with effort of work, if required we do the effort estimation on task level, Tasks are child
of user story. The Value of Story point have no how related to development or testing effort.
 At the end of each sprint/Iteration, the completed/accepted story’s story points get credited to the team.
 Keeping story point as 0 is a good practice for story type as Spikes or Discovery Story, as it not adding any
business value nor ship-able
 Average of total completed story points for 3/5 or even more sprints are called velocity of that team, Velocity is
use to measure the sustainable pace and trends of teams.

Agile Estimation Techniques for user story

Commonly used techniques to estimate a user story
There are many estimation techniques for User Story, like Delphi, Wide Band Delphi, Complexity Bucket,
Planning Poker etc. We will discuss two most commonly used techniques in software development industry
those are

1. Planning Poker
2. Complexity Bucket

Planning Poker (with Video)

Planning poker is a technique to estimate the story point or size of a user story in software development
industry using agile framework.
In this technique, The Team member Development team including Tester, Scrum Master, Product owner
participate, and optionally any external technical or functional expert can join on invite. But Only the
Development team member can estimate the user story, the development team can clarify any of their
doubts.
As per the name “planning poker” the estimator use to contain sets of cards looks like a playing cards, have the
number from Fibonacci series printed on each card. during expressing the story point each estimator shows
the card to every one to cast their feeling as a size of the user story, The Scrum master then mutually take the
most voted number and assign with the user story.

However if the team don’t have the story card handy, it will not stop them to estimate using this technique.
Then can estimate by
1. Using Poker Card (as discussed earlier)
2. Simple Speak the number
3. Raise their Fingers
4. Smart phone app for planning poker
Normally the story point estimation take place during grooming session, and mark the story to groomed status
once the story is estimated. And no further changes is advisable to that story.

Planning poker in distributed Agile Teams

We can estimate user story in a same technique, even when our team is distributed in different geographic
location. Only difference is they are connected on telephone and live screen sharing like WebEx, blue jeans etc.

Too much difference between two points from different member

We always do voting to assign the most voted story point for a story, how ever if there is a big difference
between any two voting, The Scrum master needs to intervene and ask the team member why one team
member think its that high and another team member thinks its that low.
After the discussion once again with in the team, The Team conclude a final story point to assign.

Story Points estimation Vs Effort Estimation

Remember We don’t and should not relate Story Points and Efforts.
Story Point is to estimate the Story Size, Value, Complexity, Risk , Dependencies etc
Where Tasks are the child’s of user story is to estimate its efforts in Hour, for better planning and capacity
Mapping
Complexity Bucket (with Video)
Using complexity bucket is another technique to estimate the story point for a user story.
This techniques is majorly used by calculating the technical aspects of the story, by creating matrix of Areas of
Complexity and Levels of complexity, and Aggregate the matrix values to get the story Point.
Refer the picture for your quick Reference, Or explore the video to understand how it works with a
demonstration.

Quick Image Reference for Complexity Bucket estimation

 2. Burndown Chart and how to read it.

What is Burn down chart

Agile team use Burndown chart to track remaining work, It can be scale to different level like Epic Burn Down,
Release Burndown, Sprint Burndown etc.
This article is on only Sprint Burndown chart. Sprint Burndown chart is a visual representation of remaining
works for the scrum team of a specific sprint. Burn-down charts represents the real time total amount of work
as pending for the sprint of any team, amount of work can be measured as remaining effort hours, or story
points. Using the unit as “task hours” rather than “story points” is always better for burn-down chart. I
personally suggest to use task hours to plot the burn-down chart.
In this article we will learn details about burn-down chart, with the below mentioned points
How burn-down chart gets generated and what exactly it represents? How to read burn down chart? Scenarios
when we refer our burn down chart to take decision. Read team performance from burn down chart and
define action items. Disadvantages for using Story points as burn down measurement units.

How burn-down chart gets generated and what exactly it represents?

Burn-down Chart is a sprint artifact, every sprint has their individual burn-down chart, ALM tools generate the
burn-down chart for each sprint right after sprint planning or when the any sprint starts. If you are not using
any ALM tool, then you need to manually create your burn-down chart on excel or white board based on your
convenience.
A burn-down chart have two major value area, X axis and Y axis, X axis represents the number of days for the
sprint, where the Y axis represents the amount of work. The value with in the graph is remaining work (lets
take it as hours) for any specific day with in the sprint duration.
To understand this it in more details, refer the below image followed by the explanation of the picture.

If you look into the above picture, we can notice the team has a product backlog, and during sprint backlog the
team has committed few user stories, and later the team members have distributed the task, each member
will work on with an estimated effort hours for each task. So far we have committed stories for the sprint, Each
stories have some tasks with estimated hours, and each task is assigned to respected team members.
(We are not talking about story point here, as this article will talk about burn-down chart with Task hours.)
If you total the task hours it will be some where at 110 hours. lets assume the team have a capacity of 130
hours, which we will bring into the picture little later.
Lets see the other important are of the sprint, we have a sprint start date that is 10th Dec and it is ending on
21st of Dec, which means its a two week sprint, and the sprint duration is 10 days.
So from all those information, we will pick or the ALM toll will pick two major values (as below) to plot the
burn-down chart for the first time
1. Total Days of the sprint = 10 days
2. Total committed & estimated task hours for the team = 110 Hours
If we divide the total hours by the total days means (110 /10 ) = 11 hours.
Which says, if the team complete 11 hours of work daily, then by end of the last day of the sprint , the team
will be able to complete all the work they have committed.
refer the picture below followed by the instruction to understand it better.

As we learned, that based on the example of current sprint, the team needs to work on 11 hours per day. By
end of the first day the team will be able to complete 11 hours of work from 110 total hours. so remaining
total hours will be 110 – 11 = 99 hours by end of first day. And similarly by end of 2nd day the remaining hours
of work will be 99 – 11 = 88 hours. In this fashion by end of last day the remaining hours of work will be zero.
This is the future prediction, where the ALM tool or your excel predicts that the team will be able to work on
11 hours every day and all that 11 hours will be reduce the remaining hours accordingly, the line on the
predicted value on each day is called Ideal line of burn-down chart. Which get plotted on the chart on the first
day of the sprint, the lines starts from day one to end of last day.
But in reality the remaining hours at end of every day will not be same as predicted, because of the following
reason.
1. Even after working 11 hours or more, its not necessary the remaining hours will reduce by 11
hours, because 11 hours was just the estimation, once the team start working on the real
construction, the actual hours may differ than the estimate. In agile what is important is, we don’t
care about how much work we have done, we care about how much amount of work is pending
or remaining. keeping that mantra in mind, every one update the remaining hours for each task
they have worked on. Now the system (ALM tool or your Excel) will calculate the total of
remaining hours by end of the date, and get the out of total estimated hours, how much is burned
down. If the total remaining hours at the day one is lets say 105 hours, so the total burn down on
day one is 110 – 105 = 5 hours. where in Ideal line it was 11 Hours.
2. There are possibilities of Scope creep due to product owners critical priority change. which will
increase or decrease the remaining hours suddenly, result to sudden rise or fall of the actual line.
 3. team members fall sick, that day the tasks assigned to the member may not be burned down
4. Impediments, the blocker like external dependencies, development environment etc may slow
down the predicted momentum of burn down.
5. and many other reasons.
So the system calculate the actual remaining hours up to the current date or sprint last date (which ever is
smaller), and plot a line which is called Actual burn down line
refer the below picture to understand how actual burn-down lines flows on burn-down chart
ACTUAL BURN-DOWN LINE ON DAY 3

ACTUAL BURN-DOWN LINE ON DAY 6

ACTUAL BURN-DOWN LINE ON LAST DAY

There is one more line which is very useful if you have it on your burn-down chart. That is called Capacity burn-
down line. So if we talk about the above example, the team has committed total of 110 hours of work for a 10
days sprint, where lets assume the team had a capacity of 130 hours.
The Ideal line was plotted based the commitment of 110 hours ( 11 Hours burn down every day). For capacity
burn down we can plot another smooth line based on the available capacity of 130 hours (13 hours burn down
every day).
This line is very important, will learn its importance later in this article, So far Rally or Jira does not provide this
line on their burn down, however the burndown chart in TFS have the capacity line.
Refer the below picture to get a visual of capacity burn down line.
 UNDERSTANDING CAPACITY LINE

A COMPLETE BURN DOWN CHART WITH CAPACITY LINE.

How to read Burn-down Chart ?

I believe you all already aware of sprint burn-down chart, and referring it to track the progress and remaining
work in the rest of the sprint sprint days. Here I will explain few of the areas to understand how to read the
burn-down chart. If you are new to agile or want to know more about burn-down, you may find it helpful.
As we know our burn-down chart has an ideal line and an actual line. you may have another line for capacity
line.
When ever we refer our burn down we check our actual line as of today, and compare it with the ideal line.
1. If the actual line ending anywhere above the ideal line, it means there is a risk to complete all the
stories with in the sprint duration. How big the risk is depends upon vertical distance between the
actual line end point and the ideal line.
The higher the distance is bigger the risk, because as per the commitment the remaining hours on
that day is actually more than what is supposed to be.
There can be many reasons for that and needs to take corrective action, as proactive measure.
reasons like
a.) The team is not able to give enough time to the sprint commitment.
b.) The team has under estimated the tasks.
c.) The team is not properly updating the remaining hours.
d.) The team is getting new stories after the sprint start date.
e.) The team is re-estimating the tasks hours, by increasing the remaining hours
At the same time you need to check how many days in the sprint is remaining to recover the
delay. If this situation appears during early sprint days, the team still have a chance to recover it,
however during the last days of the sprints its very difficult to adjust the delay.
The below two diagram represents two different cases where one diagram says the risk is minimal, and
another one represents high risks.
The rectangular box will not be there in your burn down. I sketched it here for better understanding, the light
orange rectangle is the size of risk.
If you have the capacity line with your burn-down, you can get better visibility to identify the probability of
resolving the risk. Even if the actual line is above the ideal line, but its below the capacity line, that means the
team will be able to complete the tasks, as it is still under their capacity.
The below two diagram represents two burn-down chart one is at risk zone another is not risk on that
particular day
2. Now Lets talk about another situation, when the actual line is always under the ideal line. Its a good sign,
but if it is too low, then the team might have over estimated, and capable to work on more work for the sprint
duration. Look at the situation. a good mature actual line should be close to the ideal line, if it is not the there
is some thing needs intervention.
3. If you notice a sudden spike up or done on your burn down, then its means the team is getting too much of
scope creep.
This is how you will read your burndown chart, during our next section will see how we can read our burndown
chart on different scenarios.

Scenarios when we refer our burn down chart to take decision

Scenario 1 : Product Owner asked to add one story as it is on high priority, and the functionality of this story is
very critical to deliver by this sprint end.
In this case, the team needs to check the current burn down chart and the actual line. How much additional
bandwidth they have as of that specific day. There can be 3 scenarios :
1. The Team can straight way agreed to the story addition to the current sprint
If the actual line ending much below the ideal line or capacity line, means have enough bandwidth available to
finish the job with in sprint duration.
Keeping in mind individual capacity from tester and development prospective. Means even if the as a whole
team there are lots of bandwidth available, but individual tester level there are not much bandwidth available,
so in this case, you might refer to option 2 below.
So you will first look into your burn down, if it says you can commit more stories, check for other constraints
and take the decision.
2. Or the Team can ask the PO to descope some low priority story, means remove from the current
sprint and move it back to backlog
If the team finds in burn down the actual line is close to the capacity line or ideal line, then the team checks
the similar size of already committed stories which are not yet started development, ask the product owner to
agree on de-scoping any(one or more) of those stories, to accommodate new critical stories.
Keep in mind, the time remaining in sprint, skill set required for the new story, and available bandwidth of
those skilled team members.
1. The team express it will be risky to add new stories on the sprint scope, and advice not to
change scope.
If the team reach to a end of the sprint there are only two to three days left, the actual line is very stable, few
stories are already completed, few are in progress. In that case taking new stories may be risky, the team can
explain to the product owner and suggest to wait for few more days to start the next sprint, and the team will
complete this story as first priority, make it deploy ready as soon as possible.
However even if it is the last few days of the sprint duration, and all the stories of current are completed and
accepted. The actual line already touched the ground. Then the team can quickly estimate and commit the
story
Scenario 2 : One of the resource needs to go on sick leave for medical emergency for couple of days.
In this case check the burndown chart and analyze the position of actual line end point. if it is ending long
under the ideal line, You may accommodate the unplanned vacation.
Check on individual level also total hours of pending work the resource has, and total number of days
remaining for the sprint.
Check any other member of same skill member has enough bandwidth to supplement the gap.
If the team feels there are potential chance of not completing all the committed stories, Then the team should
immediately inform PO, and reach to a conclusion like, identify less priority story to start last thing of the sprint
etc.
Scenario 3 : During 2nd week of the sprint testing team raised too many bugs, that needs to be resolved with
in the sprint duration.
If the tester is raising too many bugs during the testing of user stories, which is not a good sign of mature
development, but even it happens. Check you actual line and capacity line difference. How comfortable the
team is able to fix the bugs, along with the pending committed development work. The tester needs to re-test
the big fix along with committed testing work.
The burn down should have enough bandwidth, means actual line should end much lower than the capacity
line, to work on all the fixes. If Not, then next sprint onward, keep enough buffer as focus factor during your
capacity planning.
Check your definition of done (DOD) about Defect closure, If it says All P1 and P2 bugs must close to make a
story done. Check the number of P1/P2 bugs, the additional time to fix them, and bandwidth available in your
burn down.
Consider talking with your PO, to act out the worst case scenario, and identify the most low priority story and
most critical stories.
Burn down chart is the first place to decide whether you should talk to your PO now? or you need to further
drill down the possible other constraints.
There can be many other scenarios on your work, and you may find burndown chart is helpful to take decisions
on those situations.
Read team performance from burn down chart and define action items

There are many trend of sprint burndown charts actual line. Explain few typical unusual case of sprint

burndown chart, and explained what does that cause and corrective actions.

Straight Actual Line

You might have encountered your team sprint burndown have straight lines for couple of days. That can
caused by one or more of the following reasons
1. Team is not updating the remaining task hour on daily basis
2. Team has not created all the tasks, so not able to change the remaining hours
3. Task estimation was underestimated, so remaining hour are not changing
4. user stories are blocked by some impediments and those are not resolved, so the team is unable
to proceed
5. Environmental issue like development server not available to do coding or test environment not
accessible for testing
How to resolve them ?
1. Make sure each and every team member update the remaining hours of the task they are working
on daily basis.
2. During Tasking of user story, don’t take it lightly, take your time to create and estimate tasks as
accurate as possible.
3. Try to resolve the impediments, as soon as possible, if some stories are blocked, don’t wait for its
resolution, start working on the stories, if all the stories are blocked and that may take couple of
days to resolve, inform Product Owner and act accordingly.
4. Before starting the sprint map all your dependencies, resolve the dependencies first then commit
the story, till the time the dependencies are not resolved work on independent stories.
5. Resolve all environmental issue, check availability and accessibility before starting the sprint.
 Actual line touching the ground much before the last date of the sprint

If you notice that the actual line is touching the ground much before the ideal line, that means one or more of
these.
1. The team has worked aggressively, burned more hours per day as per the capacity
2. The Team has committed less than the capacity
3. The team has over estimated the task.
Resolution.
1. If the team willingly work hard, its good, but its always better to have defined hours of work to be
done. working extra hours every day may cause other negative effects. Plan your capacity based
on the best optimized amount of work the team can perform.
2. If the team commits less than the capacity, that happened because most of the time because of
insufficient amount of requirement, Product Owner may not have enough story ready to commit
at the time of planning. Work on frequent and regular grooming to have your backlog healthy.
3. Estimate fare, make it as accurate as possible
 Actual line have Sudden Spike

If you notice that your actual burn down line has a sudden spike upward, its means there are
1. change on scope (Scope Increased between sprint duration), You PO may have asked to add one
or few stories to the current sprint.
2. Or the team has re-estimated the task to increase the remaining work.
Resolution
1. Mature up your Sprint Planning, Have your backlog healthy so that you can fully utilize your
capacity during sprint planning, by committing max possible product backlog item in priority.
2. Do a task breakdown thoroughly, create all the possible tasks created, estimated and assigned. so
that you don’t need to re-estimate during sprint duration.
Ideal line and capacity line have too much difference on day 1
If your ideal line and capacity line have a big distance means, The team has not committed their full capacity.
because of
1. Unavailability of enough user stories in ready state, so team has ended up the sprint planning with
2. or Team is not confident to utilize the full capacity, hence only partial capacity.
How to resolve this situations for future sprints.
1. Again Continuous backlog grooming to have healthy backlog of ready to work on Items.
2. Understand the requirement in details covering all aspects. Then only commit the user story
during sprint planning. Let individual team member create, estimate and assigned tasks for them.
continue the planning till the max capacity utilized.
Actual line is out side the ideal line for consistence days and difference in increasing.

This state is very risky, and a clear indication that the team will not be able to complete all the committed work
item by end of the sprint. This cause because of many reason like
1. Even the team is working as expected, but they are not updating the remaining hours.
2. The Team is actually not working
3. The Team is blocked or impeded.
4. The team has found estimated task hours are too low, need to work more, insted of re-estimating
the task, they are not updating the remaining hours, working to bring the remaining hours as per
burn down.
How to resolve this case, for this sprint or Future sprint.
1. Please update the remaining hours every day, it may bring some spike, it will depict the real
picture.
2. Rest of the cases resolution varies from team to team, analyze it and take a best suited corrective
action.
 Straight lines and Sudden drop of actual line

This is the typical case, you might have encountered, The reason behind this can be because any of these
reasons
1. Mostly occurs, when team use story points as y axis of their burn down.
2. remaining work updates are not happening, regularly.
3. remaining work updates happen only on last date of the sprint as a formality.
How to work on this
1. Start task breakdown, and have the Y axis of your burndown with task hours.
2. Update Remaining hours on daily basis.
Will talk about why we should not use story point as Y axis of our Sprint burndown on the following section
Disadvantages for using Story points as burn down measurement units.
The purpose of Sprint Burndown Chart is to track the remaining amount of work, It has to be referred every
day, and the team make the strategy of the work they will perform for the day. So every day it has to burn
down.
In case of Story Points, its not necessary every day one story will get completed, even the team has already
worked on it and burned some work. So even the work has burned down, the chart of burndown on story
point will now reflect any changes. A story with any story point lets say 5 SP can either be completed or not
completed, it will not burn as 5 to 3 to 2 to 1. Once the story is completed the the story point will remain same
as 5, only the state will change to done. So you will see a zigzag burndown instead of real reaming amount of
work as of that specific day.
The Stories are counted as completed when it is verified and accepted by the Product Owner. many times a
development and testing completed story not gets verified by product owner, as Product Owner along with
development team have not started working as team and PO gives priority to other activity, which created
delay on story acceptance. and results become visible on your Sprint burndown chart.
Remember this article is only on Sprint Burn Down chart. The Epic and Release burn down can be plotted using
Story Points.
Below mentioned three sample sprint burndown chart, to refer and compare difference between sprint
burndown on Hours and Story Points.
 3. What is Daily Scrum Call or Stand-up Meeting
Daily Scrum meeting is also called can Scrum call or Standup meeting. This meeting own by the Scrum team,
happens mostly during beginning of every day. Should last for max 15 minutes. Where the development team
member discuss on the work they have done, and make the strategy to work for the day. The highlight the
impediments if any. This meeting ideally take place at same time and same place.
For a co-located team all the participants stand in-front of the physical scrum board (ideally the task board)
and talk story by story or person by person, Scrum Master facilitate and take ownership of any impediments or
provide updates with presence of PO.
Though its majorly known as daily scrum call, both Scrum and Kanban team ideally conduct this agile
ceremony.
We will discuss in details of the daily scrum call on each and every part of it in this article.

Basic Rules of Daily Scrum Call.

 This meeting own by the Team not by Scrum Master or Product Owner.
 Its not a Status update meeting
 This meeting should not exceed 15 minutes.
 This meeting should be conducted every working day, during beginning of the day
 This meeting should place at same place and same time every day.
 All development team member must attend the meeting, even they don’t have any pending work. Scrum
master and Product owner are optional. But it’s good to have the presence of entire Scrum team.
 If the team (or majority of the team member) is co-located, all team member should stand up for 15
minutes.
 The team should talk about
>> What they have worked on yesterday
>> What they are planning to do today, and Make the strategy for the day.
>> If there are any blocker or impediments, that stopping the team to work.
Daily Scrum Call – Good Practices and what to avoid

Good Practices
1. Rules : Follow and stick to the Rules of Daily scrum call as mentioned above
2. State You Name:Everyone Please state your name before you start talking about yours tasks.
3. Speak Loud: So everyone can pay attention , who is physically present near the speaker or at Phone.
4. Working from Home? : Please attend the bridge
5. Task Remaining Hours : Update the task remaining hours before starting your DSM. To have the board
populated properly and actual burn down.
6. Burn down Chart : Scrum Master please check the burn-down after end of DSM every day, and take action
if required
7. Long discussion items: Park the long discussion at sidebar for core hour discussion (After DSM) . its also
called 16th Minute discussion item
8. Team member on Planned Leave: If any team member on Plan Leave? Please send the information to peer
by end of your last working day.
9. Distributed team: Open a bridge and screen sharing : Share your screen with ALM open and point your
mouse on the task you are talking about.
10. DSM Duration: Try to complete the Scrum call / standup meeting in 15 Minutes.
11. After the Scrum call: quick check on individual load, and take appropriate action in case of overloading to
avoid risk.
12. Keep a Note: Keep a quick Note for all your task and you want to talk about, that will help
you quickly discuss the points. Instead of spending time to remember it during DSM or searching the entire
board
13. Impediments:Talk about all the impediments and resolution, and its risk to meet the commitment.
14. Cell Phone: Please get yourself detached from your cell phone for 15 minutes.
 Avoid
1. Avoid interference of anyone outside of the scrum team during that 15 minutes.
2. Use of term “Status” or “Update”.Its Not a Status update meeting.
3. Avoid technical discussion during DSM – Park it for Core Hour discussion.
4. Avoid Requirement Clarification that may take long time – Park it for Core Hour Discussion, or next
grooming session. Or Conduct an immediate grooming session
5. Avoid Side discussions, focus on the active discussion for Daily Scrum
6. Avoid change of the meeting time
7. Provide your update to the entire team. Avoid giving updates to Scrum Master or Product owner or any
limited number to team member.
8. Avoid losing focus or distracted, even if you don’t have anything to contribute. If you are part of the
meeting put your 100% to listen and understand (if not speaking). Stay top on the ALM tool (may on a
shared screen), or Physical board
9.

Participants of Daily Scrum Call or Daily Stand up Meeting

Scrum call primarily owned by the development team. so its very important all the development team should
participate this meeting very religiously. However The participation of Scrum Master and product owner make
the meeting more fruitful and effective. So to have the presence of all the three roles (as mentioned below) is
definitely a good practice.
 Participants of daily scrum call or stand up meeting (in MoSCoW)
1. All development Team Member (must attend)
2. Scrum Master (should attend)
3. Product Owner (Could attend)
4. any one (Won’t)
Lets try to understand the basic responsibility of the three primary scrum roles during daily scrum call.

Scrum Roles and responsibility during daily scrum call or daily stand up meeting
Development Team Responsibility during Daily Scrum Call or Stand up Meeting.
Individually
1. Talk about the three agenda
 What did you do yesterday
 What are you planning to do today
 Is there any impediments, blocking you to progress
2. Join the call on time, without delay. every day
3. Give the task updates to all team members not to scrum master nor any selective team member
4. Give your task update to your peer, in case you feel that you will not able to attend the Daily scrum call on
time, or will be on leave or vacation. You don’t need to give the updates every day when you are on
vacation. give the update on your last working day before vacation.
5. Give the task updates of any peer member in case of they or on leave or vacation.
6. Update remaining hours against each task before daily scrum call. So that you can utilize the scrum call
time effectively.
7. Make small notes of all the tasks that you want to talk about, or any other associated details. In the 15
minute time box if you spend time searching information, people may loose focus, and the team will waste
time on unnecessary activity. And if you are having your daily scrum call in front of the physical board, you
may not have your PC or note book accessible.
8. Refer individual remaining work and days remaining in the sprint. Raise your voice if you think its getting
difficult to complete the task with in sprint. consult with your peer member and find out the best possible
solution. take preventive action rather then corrective.
9. Move your task card in your task board, from one column to another based on your scrum board workflow
and the task’s story card.
10. Ask Product Owner related to any small question regarding requirement understanding. Remember If the
discussion will take longer time, park it for your core hour discussion or 16th minute discussion.
As a Team
1. Check the burn down chart, and find out if the team is progress is in risk. make a strategy for the day and
rest of the sprint duration.
2. Re-assign tasks to normalize over loading. and keep a balance between task effort allocation and remaining
days of the sprint
3. Think together, plan and act accordingly to complete the story as a whole not the individual task. Even if
one task remains incomplete, the story will be treated as incomplete. So when you are making a strategy of
which task who will work when, be careful of the sequential tasks. A testing task can start when the
development task is completed, So if you only think about only your task of development and think you can
complete the task before end of the sprint last day, then the tester will not be able to get time to test your
change. And if there is any defects raised by the tester, the the developer needs to fix and followed by re
verification.
Scrum Master’s Responsibility during Daily Scrum Call or Stand up Meeting.
The Scrum Master are treated as local coach for the team. till the time team is not getting matured enough to
run as self organized fashion, Scrum Master drives the daily scrum call and continuously focus on maturing the
team, so that they can become self organized. Along with that, a Scrum Master also have the below
mentioned responsibilities.
1. Based on team composition, and distribution, find a best time and place to conduct this 15 minute
discussion and schedule a recurring meeting to the scrum team including product owner. preferable
morning time of developers time zone.
2. Facilitate the scrum call, let the team drive it by them. Make sure the team is following the scrum call rules.
3. protect the call from outsider interference
4. stop the long running discussion and park it for 16th minute discussion. Also let those open discussion
happen after daily scrum call.
5. Enforce on-time start and end of the meeting.
6. Make sure team is covering ll the items in progress. And if any story can come in progress.
7. Check if any one is overloaded or under occupied and ask the team to balance it.
8. Have a quick look on the burn down chart and identify potential slippage of commitment. and take
proactive action.
9. Take ownership of impediments and give updates on them everyday Daily scrum call
10. Ask product owner to verify the completed stories (if any) to mark it done.
11. Ensure the team is following the definition of Done.
12. Ensure the story cards and task cards in scrum board represents right states of the sprint progress.
Product Owner’s Responsibility during Daily Scrum Call or Stand up Meeting.
Products Owners are not mandatory for daily scrum call, However I encourage to have Product Owners
presence in daily scrum call. That will help him to understand what is happening on the sprint.
And also
1. The team member can give heads up on the doubts they have, and needs to discuss in details. Mainly to
remove any gap on requirement understanding.
2. Scrum Master or team can update about the stories to product owner those are completed and ready to
review.
3. Product owner can update about any impediments that he/she is resolving.
 Purpose of daily scrum call or Daily Stand up Meeting
1. Increase Team co-ordination, and working together to meet a common goal.
2. Increase transparency of Sprint progress, dependencies, and Risks.
3. Increase opportunity to take proactive decession.
4. Increase Team bonding and self organization
5. Identify road blockers in advance and act accordingly.
6. Make strategy for the day.

Why Standing up ?
The daily stand-up meeting which is also known as a “daily scrum”, a “daily huddle”, “morning roll-call”. is
practically a quick synchronization meeting with in individual team.
Traditionally the scrum team mostly used to be collocated. where the team used to gather together at one
place during their morning time for 15 minute for daily stand-up meeting in-front of the physical board. they
used to to keep standing and share their updates with in team.
The main reason of conducting this meeting being standing up is to keep the focus on the main agenda of the
daily stand up. The team avoids long discussion, and restrict external interference.
Now in modern days the Scrum teams started working from distributed location, they refer digital scrum
board, and rarely get a chance to meet with each other by person. So standing up does not make much sense
from their own desk. A the name of the meeting is become changing from “Daily Stand-up-meeting” to Daily
Scrum Call” or “Daily Huddle”.
I will still emphasize on conducting this Scrum call, Standing up if your team members are co-located, or mostly
co-located.

Scrum Call Approach for Distributed and Co-located team ?

Co-Located Team
You may be part of a co-located agile team, or distributed agile team. In both the cases the over all rules, roles
and responsibility will be remain same. Co-located team get the advantage to gather physically for daily
huddle, most of the time the use a Physical Scrum Board or Kan-ban Board. Now a days all teams are getting
digital, by using ALM tools like Rally, Jira, Version on etc. and use of the Physical board is fading out eventually.
During Daily Scrum These team members used to stand up for 15 min. These teams can easily plan their Daily
call during there morning Time.
Distributed Team
On the other hand, If the team is distributed, Physical board does not add values to everyone, as it is not
accessible to every one. However availability Digital board with in the ALM tools, fills the gap of Physical board,
and works out pretty well. However they team lacks the physical presence of there member. And does not
needs to be stand up, As every one is referring to a small screen rather than a big physical board.
The team meets through Screen sharing apps like Webex, Skype, BlueJeans etc. Many team prefer to do a
video Conf to get to see each other.
If the distribution of the team is withing same time zone, its good. But if there are different time zone evolved.
Its practically not possible to schedule the meeting at everyone morning. So mostly the team mutually decides
to have the Daily Scrum Call at the morning time, where majority of the Development team is there.
Because of the different time zone. many times the Daily scrum call get extended, as the team member from
two different time zone generally gets this time to share their thoughts, Ideas and sprint progress. However in
that case try to complete the Scrum Call, identify the long running discussion, and park them for later. Once
the main agenda of the Daily scrum call is over, make a logical end of the Daily Scrum Call. and start the
discussion you have parked for, here the only required member can stay, rest can drop off.

Outcome of Daily Scrum Call

Common Understanding of Team Progress
Meeting with the team sharing what they are working on, what they are planning to do today to meet the
common goal of the sprint, improves the common understanding of the team about the progress on their
commitment for the sprint.
Execution Strategy for the Day
Based on the current state and progress, they team makes the strategy for the day, who will work on what
task, which task needs to be finished first, how to utilize the sprint time in most optimized way.
An Updated Sprint Backlog
Continuous acceptance and progress on Task and sprint level updates the sprint backlog on daily basis. Gives
better visibility to the team, or management level. It also contribute on consolidated reports to reflect real
time states.
And Updated Scrum Board or Sprint Board
The teal also update the task Remaining hours, Task card and Story Cards placement in sprint board. and make
the Sprint board or Scrum Board up-to date.
Challenges of Daily Scrum Call
Time for distributed time zone,
Apart from not able to follow the basic rules of Scrum Call, the biggest challenges is to define a time when the
team is distributed, and team is located at two different time zone. As its is good to have in the morning time,
its become difficult to identify , morning of which time zone. So in those situation, plan the Daily Scrum call at
the morning of time time zone where majority of the development teams are working from.
Mindset
Reaching to a mature mindset of that, this 15 minute discussion is not a status update meeting, that you need
to update your Product Owner or Scrum Master or any one about the progress. The team just need to discuss
with in them and prepare a strategy for the day.
Giving Importance
If the team (Dev Team + Scrum Master + Product Owner) don’t utilize time for the purpose it is meant for, or
even they were forced to do so. The Agile team will not get the real expected outcome of the meeting and it
will impact the over all performance of the team also the agile value. The team will eventually loose interest of
the Daily Scrum Call. And for the team the Daily Scrum Call become just a formality or burden.
 4. Why do we need Prioritization ?
We all do prioritization on our every day life, because we have limited time for every set of items to
execute, and that’s why we choose the most important actions to execute first and followed by lesser
important.
Similarly we prioritize functionality or tasks in software development, because few functionalities are more
important than others.
Let me explain few real life situation, and how we prioritize our actions with in that situation, and then will
relate those concepts in the situation of software development to prioritize stories in Product Backlog.

Real Life Situation Software Development

SITUATION 1 SITUATION 2 SITUATION 3 SITUATION : PRODUCT
30 min break with in 1 Identifying expenses Visiting remote town far BACKLOG
day training, Your phone with limited budget. from your home location
PRIORITIZATION.
was switched off during for business purpose,
the training, You found and planning to meet you have 35 stories in
10 missed call during the few of your friends and backlog not yet
break. and wants to call family member as on committed, want to
back few of them. when you get time from prioritize the stories for
your business meetings. next sprint.

TIMEBOX

Situation 1 Situation 2 Situation 3 Situation : Backlog

30 Minutes. Amount of Money 1 Week Prioritization
3 Weeks

Story / Functionality / action to execute

Situation 1 Situation 2 Situation 3 Situation : Backlog

10 Missed call to call 10 Expenses, Like 10 Friends at different Prioritization
back Electricity bill, buying location to visit 35 Stories to work on
new furniture etc
What to Prioritize

Situation 1 Situation 2 Situation 3 Situation : Backlog

Whom Should I call first What are the expenses I The sequence of the Prioritization
and whom should I call should plan first, and friend I will meet, so that Which story should I put
later. and order I will call can not skip, and what In case If I don’t get top of my list by making
them are the nice to have kind enough time to meet all, its rank 1, and followed
of expenses I can plan at-least I will end up by my comparatively less
for latter. meeting most important important stories. So
friends. that during sprint
planning or grooming I
can identify which story
to pick first followed by
the next story in rank.
 What to consider during Prioritization

Situation 1 Situation 2 Situation 3 Situation : Backlog

 Possible duration of  Amount of each  Distance from my Prioritization
the call expense business location  Business Value of
 importance to make  how important to  what are the each story
that call make that expense importance level its  Amount of work for
 any other call related Related or depended is, for you to the stories
to the important expenses meet your each  Associated Risks and
calls friends. its mitigation time
 friends living in close for the stories
proximity  Dependencies
associated with the
stories
 any related story,
can be done
together

What is Product backlog Prioritization ?

Product Backlog prioritization is one of most important exercise in agile software development. Any projects is
successful if the stakeholders or clients or business gets most valued functionality at earliest. And that is
possible by effectively and consistently prioritizing the requirements (users stories).
Backlog prioritization is required to organize the product backlog items (user story/Defects/Spike etc) to make
the sequence of its development and deployment.
This Sequence is followed by the scrum team to choose product backlog items during grooming or sprint
planning.
The influencing factors for prioritizing product backlog items are
1. Customer Satisfaction
2. Business Value
3. Complexity
4. Risk & Opportunity
5. Cost
BENEFITS OF BACKLOG PRIORITIZATION
These are the key benefits of an effective and consistent backlog prioratization
Business Benefits

 Fastest return of investment

 Customer or Business satisfaction
 Better management of dependencies
 Minimizing Risks
 Keep focused on Value driven development.
Benefits to the Scrum Team

 Effective Grooming by saving time of selection story

 Effective Sprint Planning by saving time of selection story
 Better visibility to pick stories within current sprint scope, if there are bandwidth
 Better visibility to drop stories from current sprint scope, if bandwidth reduce because of many reasons like
Team members absence, emergency production fix etc.
TREATMENT OF DIFFERENT BACKLOG ITEMS DURING PRIORITIZATION
All Items in product backlog are treated equally during backlog privatization, that can include, Defects or Bug,
New Functionality, Enhancements, Spikes.
What to Consider during prioritizing agile work item?
THERE ARE MANY INFLUENCING FACTORS TO CONSIDER DURING PRIORITIZING BACKLOG ITEMS.
MOST IMPORTANT CONSIDERATION FACTORS ARE.
1. Customer Satisfaction
We always prioritize stories by keeping in mind the factor of customer satisfaction, by assigning the
functionality (backlog item) a high priority that have have a probability of higher customer satisfaction. and
prioritize those functionality first without those customer may get dissatisfied.
So we need to implement the basic needs first , then the performance area, and then the delightful
functionality
check out the section below for Techniques of product Backlog prioritization, below that explains Kano Model
to understand how measurement of customer satisfaction help us to prioritize our Product backlog item
2. Business Value
Understanding the business strategy and business goal is very essential to prioritize the functionality. That’s
why the product owner or the business Analyst are best person to prioritize product backlog item. Identifying
which functionality will add most value to meet the business goal is helpful to prioritize the product backlog
item.
The sponsor, Sales team, or strategic thinker influence the business value by targeting long term benefit or
immediate value addition to counter competitors.
3. Effected number of users / or frequency of use
This factor is product specific, not everywhere considered as prioritization factor. The functionality may be
prioritize by keeping in mind the number of users will be effected. for an example, in a eCommerce web site
look and feel of consumer home page will get higher priority than a supplier home page.
Similarly if a functionality will be used more often, that should be prioritize early to work on any additional
optimization work for it if needed.
4. Cost to develop and implement the functionality
High cost not necessarily be on low priority, we need to think rationally, about each functionality’s cost and
ROI. Cost is not the only factor, during prioritizing we need to think about the return of the functionality as
well.
Definitely Low cost – High return will be on top priority and similarly High cost – low return can be low priority.
But High cost – high return can also be at top of the list, considering other factors of prioritization.
5. Risks
Ranking high risks functionality in top of the list, maximize the early mitigation. Where keeping high risk
functionality for later stage of the project, increase overall risk of implementation.
6. Complexity
Functionality with high complexity or difficult, is advisable to start working on early stages of the project, As
the team is fresh so allocation of skilled and experience member is easy. And If it takes more time than
estimated, the team will also have more room to adjust the extra time.
Lets utilize these consideration factor to get the Priority rank
There are many techniques to prioritize product backlog, we will discuss in details about MoSCoW method and
Kano Model, later in this article.
Here lets talk about getting the priority by considering few of the above factors.

PREREQUISITES :
1. Identify the factors your project will consider to analyze the priority, you can use all the above factors or
most impact-full factors to do this exercise in this example we are using three factors a.) Customer
Satisfaction, b.) Business Value, c.) Cost.
2. Allocate the weightage to each consideration factor, in case you think all the factors are of equal weight
for your particular project, just give 1 to all. in this example we have allocated 12 to Customer satisfaction,
10 to Business Value and 7 to cost.
3. Have your backlog ready with the items including Defects, stories, Spikes etc. In this example we are
assuming our backlog have 10 stories that we are prioritizing.
4. Define a scale to provide rate to each story against its consideration factors. In this example we are having
a scale of 1 to 10.
Refer the below Matrix. followed by the explanation, to get the calculation mechanism to achieve the priority
Ranks

EXPLANATION
In this matrix has the consideration factors and its weightage as column and the 9 backlog items (Story 1 to
story 9) as row.
The numbers inside the matrix are the relative values to denote the rate for each story for its respected
consideration factor. The rates are in a scale of 1 to 10.
Each story has a total value in the 2nd last column. Its represents the cumulative value of all the factor’s
value for that story. Factors value for a story is calculated as weight multiply by its Rate .
The last column represent the priority or rank of the story, maximum value is on high priority with rank 1, and
minimum value is low priority. In this example the top priority story is story 6, and lowest priority story is story
3 and story 4.
End of Section Product backlog Prioritization
Scrum team members role during Prioritization?

Product Owner
The Product Owner is responsible for prioritizing the product backlog, and ensure the team delivers to the
customer, most valuable functionality first.

Scrum Master
The Scrum Master facilitate the prioritization, by working closely with product owner, and does not work
directly to prioritize backlog items.

Development Team
The development team members are typically observe the process, and may provide inputs on request.

Facilitate
by Scrum Master.
When to prioritize stories in Backlog?
Backlog prioritization exercise is advisable to conduct frequently, at least once a week. the candidate backlog
items for prioritization are depend upon what stages that item is in.
Generally Backlog Items under Initial stage (Backlog) or in Groomed or Defines stage are potential candidates
for prioritization.
The Backlog item those are already committed for the current sprint, or currently in progress, or completed or
accepted, does not need to be prioritized. Because those are already prioritized or ready to deploy.
Some prioritization techniques needs the size or estimated value to prioritize, thus it take only the backlog
items from Defined/ Groomed state to prioritize.
Backlog items in different state to prioritize

Techniques to Prioritize Product Backlog Items

There are many ways of doing prioritization. most commonly are as below
Affinity Analysis

With this technique we categorize our user stories into different baskets like high low medium etc. and pick
backlog items to groom, plan or construct. This is techniques of basketing Product backlog items to prioritize in
groups.
Play the video below to watch practical demonstration in ALM tools like Jira, Rally etc. prioritizing backlog with
different techniques including affinity analysis.
Kano Analysis

With this technique we arrange our backlog items, rather I will say the functionalities, keeping in mind
the customer satisfaction factor. The Kano Analysis chart have different areas of customer satisfaction, and we
place our backlog items on those areas, and prioritize accordingly. The different areas of functionality are as
below
1. Must be Functionality
Customer usually take those functionality for granter, If implemented customers are just neutral, but if not
implemented or poorly implemented, customers are very dissatisfied.
2. One Dimensional Functionality
Those are the functionality satisfied the customer if implemented and dissatisfied if not implemented.
Those functionalities are often discussed with mutually agreement between development team and
business/customer.
3. Attractive Functionality
Those are the functionality satisfied the customer if implemented but don’t dissatisfied the customer if not
implemented. Those functionality are often not demanded by the customer, but customers get delighted
by having those functionality.
4. Performance Functionality
Those are the functionality are proportional to implementation and satisfaction. More we implement more
the satisfaction will be.
5. Indifferent Functionality
These functionalities are nutral nor good or bad, implenting them or not implementing them does not
satifiy or dissatisfy the customer.
Play the video below to watch details of Kano Analysis and how we can prioritize our backlog items using this
technique.
MoSCoW Method
MoSCoW is another method of prioritizing work items in Product development. The acronym derived from the
first letter of its 4 prioritizing category (Must Have, Should Have, Could Have, Would like to have). This is
another way of Affinity analysis by basketing the product backlog items in four categories.
As the name of the each category, team prioritize the Must have functionality first followed by Should
have, Could have and would like to have, to get the return of benefit faster, reduce the lose of high importance
functionality in case of time or budget constraint.
Play the video below to watch practical use of prioritizing backlog items in ALM tools like Rally and Jira.
Ranking

Ranking items is another way of prioritizing backlog items in stack, A rank value (1,2,3,4,5…). With this method
we organize our backlog items in stack, one above another. The Rank 1 considered as high priority than rank 2.
In our backlog the higher ( low number value) rank or high priority appears above the relatively lower rank
(high number value). We pick the top product backlog item first to groom, plan, construct etc followed by the
lower rank.
Play the video below to watch practical demonstration of prioritizing product backlog item using Ranking
method.
 5. What is Product Backlog Grooming
Product Backlog Grooming, Its a most useful ceremony for the scrum teams to define the stories, by maturing
up its content, clarify doubts and questions, size relatively And make the story ready to start working on it any
time. Most of the team/organization get the benefits of grooming by conducting this ceremony religiously,
however few teams/organization still in a debate of using it, or not giving enough importance to this
ceremony. A team can achieve a well maintained healthy product backlog by conducting this ceremony
effectively and regularly.

This ceremony is also known as Product Backlog Refinement or Product Backlog Management

In this Article and video tutorial we will learn every details of Product backlog grooming, Team members role in
Grooming , whats are the benefits, Insights and Action item in the Product backlog grooming, How to Measure
effectiveness of Grooming, What exactly we do in Grooming, etc.

Why we groom stories in backlog?

There are many advantages of product backlog grooming, few of them are listed below.
 Increase efficiency by removing uncertainty and unknown facts of a user story.
 Identify the Dependencies (within Team and Cross functional) and Risks in advance to plan accordingly.
 Better estimation and Avoid rework (development, testing and implementation)
 Gives a clarity to developer and Tester about its requirement that saves time to the development team for
further discussion during sprint cycle.
 Ensuring a story is following INVEST, which gives a better sense mature user story
 Effective Sprint Planning: by focusing on only planning during Sprint planning ceremony. If the stories are
Groomed and prioritized at the time of sprint planning PO or Dev team need not to spend much time to groom
or estimate the story.
 Enforce 1st level of Prioritization to pick stories for grooming, planning etc.
 Provide one or many chances to the product Owner / Business Analyst / Story author to enhance the
requirements with more information if required.
 During Grooming if the Development team encounter some doubts or questions and that needs more time for
the POs to colaborate, then the team can park the story from that grooming session so that PO/SA/BA can
update the story with more required information and cover the story on subsequent Grooming session.
 Better management of Product Goal, Sprint Goal and milestone meeting.
Who is responsible for backlog Grooming?
Team Member’s roles and responsibility during product backlog Grooming.
There are three primary roles in a Scrum team, Product Owner, Scrum Master and the Development team
including QA. Every one of the scrum team participate in a grooming session, plus optionally or when
invited/requested by the team cross functional team members like DBA, UX/UI, Technical SME, Story Author,
Business Analyst etc can also participate in a grooming session to add more details and value to the grooming
session.
Below mention are the primary roles and responsibility of the team members in a Grooming session.

Product Owner
Pre Grooming
 Create User stories (some times with team collaboration) keeping the INVEST and Definition of ready in
Mind
 Prioritize the backlog, So that team can groom the story in prioritized Sequence.
 Explain the requirement of the user stories one by one, about its Acceptance Criteria, wireframe, Expected
design, Business logic, etc.
During Grooming
 clarify doubts of the development team, Tester or any cross functional team members.
 Split big stories to smaller stories keeping INVEST in mind.
 update the Story points after team decide the Story points.
 Update the story state once the story is identified as Groomed and meeting the Definition of Ready.

Scrum Master
Pre Grooming
 Schedule and organize the ceremony
 Co-ordinate with Product owner/Story Author / Business Analyst to identify the potential prioritized Story
to be groomed, and informed the development team to prepare accordingly.
During Grooming
 Facilitate the Grooming Session
 Ensuring time box and best utilization of the time for the purpose of the Grooming only
 Facilitate Estimation for the user stories.
 Ensuring definition of ready and INVEST is meeting before declaring the story as groomed.
 Note details for MOM or reporting.
 Facilitate if a story is too big and can be breakdown.
 Put the story on hold for grooming, in case further clarification required.
Post Grooming
 Send out Minutes of meetings, with list of stories with story points to all interested parties
 Send out Backlog Health report

Development Team
Pre Grooming
 Go through the stories to be groomed and prepare accordingly
During Grooming
 Understand the requirement
 Clarify doubts
 Participate on maturing up the story description and acceptance criteria.
 Map dependencies if any
 Map Risks if any
 Participate in Story point estimation

Other Memeber
Pre Grooming
 Possibly Go through the stories to be groomed and prepare according to support from out side the team
During Grooming
 Understand the requirement
 Clarify doubts
 Provides input to the team about the need of cross functional dependencies and complexity

When a Team should conduct Backlog Grooming?

Frequency of Backlog grooming
There is no defined time as per book to conduct your grooming session. Its not part of any Sprint / Iteration or
Release. Grooming is a ongoing activity each team needs to conduct to make and keep the backlog healthy and
a sustainable pace. Each team can groom once, twice or even more times per week. And can have 1 to 2 Hour
per session. Its all depend upon how fast and details analysis and discussion the team is doing for each story.
I have explained a calculation that may help you, to find out how frequently and when you should schedule or
plan your Grooming.
Goal : Plan and execute Backlog grooming to have twice of your average velocity ready at any given point of
time.
example : if your velocity is 30 Story Points (SP), The backlog should have 60 SP of groomed stories ( here the
backlog means the stories in backlog those were not committed ever, means [all SP ] minus [SP from past and
current Sprint])
Assumptions :
 Calculate the Velocity as last 6 sprints Average.
 Sprint Duration is 2 Weeks.
 Scrum Master have a log of each Grooming session’s Time and Groomed Story Points.
As Calculated, Schedule At-least
45 Min / 2 times a week
Or
1 Hr 30 Min / 1 time a week
Note :
 If there is already some Groomed story in Backlog, Calculate it accordingly
 After Every Sprint Planning Backlog Health get reduced as Groomed Stories are being committed by the
team
 You should Schedule more than the calculated time, mainly if you have big prioritized backlog.
 One Product Backlog and multiple teams
 We don’t Groom too much in advance because, Situation can deprioritize groomed story, result into waste
of curtail time.
Why a team should not schedule Grooming on or just before Sprint Planning.
Many times the team encountered the following challenges during Grooming.
1. Few stories may not ready as per definition of ready,
2. Few stories needs more information to make it ready.
3. The Product Owner needs some time to clarify some of the doubts or clarification raised by
Developer/Tester
4. Identified Dependencies needs cross functional team’s buy in to commit for the current sprint, The Cross
functional team may not have available bandwidth at the end moment.
5. Inefficient use of capacity, lowering the Velocity by committing less number of stories then the team is
capable of.
6. Leaving a chance of Scoop Creep, by introducing new stories in Sprint Duration to compensate the
available capacity.
7. Introduce a practice of committing unwanted Technical Spikes that produce no Values to the Business.
8. etc.
Due to these challenges, the team use to skip the story from the grooming and park it for next grooming
session. If the team commit the story with all these open questions, then
1. The team is actually putting the commitment in Risk and have a high chance to hit the commitment
reliability
2. Developing a requirement with uncertainty, Resulting Bug is production / UAT or Test environment.

Details Insight of Backlog Grooming.

What the team needs to do in Grooming
Clarify Requirement :
Clarifying the requirement is the most important goal of Grooming user story. All development team members
must participate this ceremony, and understand the ask of the user story, what is the expectation of Product
Owner or business user from the story. They talk about the requirement, clarify doubts if any, analyze risks
and dependencies etc.
If the user story need involvement of cross functional team, the scrum master facilitate the availability and
presence of the external team member to take part in this grooming session, so that the development team
gets the transparent clarity of the requirement. So that they can develop and test as per expectation with most
optimized time without fail and bugs.
If any doubts or questions remain unanswered, Team park this story for future Grooming session, so that the
responsible party can do the homework and clarify all doubts next time. And then the team pick the next story
from backlog (preferably prioritized) and start grooming
Look into each story about :
INVEST
The team including SM and PO check about the characteristics of story. And if its not matching INVEST they try
to make changes / add contents to the user story or break it into smaller user stories etc.
INVEST is a acronym which stands for
Independent – Negotiable – Valuable – Estimable – Small – Testable.
To Know more about Invest learn about Characteristics of User Story

Structure – 3C
The Team Check the structure of the user story. A Good user story should have three part : Card, Conversation
and Confirmation. To Know more about 3C learn about Structure of User Story

Splitting Large Story to smaller stories :

The Team always try to make the story smallest possible, keeping in mind each story should be potentially
shippable and following INVEST.
Many times a User story requirement is too big to estimate or fit into one sprint or capture the details in one
user story or for many other reasons the team should try to make the user story smallest possible, for easy
management, tracking and execution.
Check the Acceptance Criteria :
The Acceptance Criteria must exist for a user story. Those are the criteria the tester will be using to validate
the development.
The Development team and the Testers must understand the acceptance criteria and find outs its feasibility,
dependencies, clarify doubts, The Presence of Technical/Domain experts can provide their inputs in case its
required.
Refer the Example of User Story to understand More about Acceptance Criteria
Estimate Story Points :
The team should estimate the Story points in grooming session. Estimate only the story points not the task
hours or efforts.
Refer the article Story Points Estimation for details understanding of Story Point Estimation
Verify the Definition of Ready :
Many Teams maintain a Definition of Ready, The Definition mainly have the checklist. We will explain the
definition of Ready in details on some other article. Here are few items from the Definition of Ready
1.The Story should have a Title
2.The Story Should have an acceptance criteria
3.The Story should have a Estimated Story Point
4.….
The team verify that the story is meeting all the checkpoints under definition of ready, before declaring the
story is now groomed.
Change The State of the Story :
Finally, once all team member mutually agree that the story is now groomed, SM or PO can mark the story as
groomed by changing its state. All user story have 4 to 5 different stages, different ALM tools named it
separately, or you can customize the workflow based upon your need.
In Rally mark it as Defined, in TFS mark it as Approved, You can customize Jira workflow and have a state
named Groomed.
The ultimate goal here is to mark the story in a way so that you can filter out all your groomed / non groomed
story easily, and also utilize this state on your various reporting and metrics.
For more on user story states, refer Story State under Associations of user story

Metrics to measure backlog health or grooming state.

There are not much metrics can be required for grooming. You can analyze your grooming practice and target
to increase your backlog health and grooming efficiency.
I have explained two metrics that can help you achieve a better backlog health and increase efficiency of your
grooming.

Backlog Health
Assuming your organization standard is to maintain a backlog health by having groomed story of two future
sprint. This can be calculated by multiplying your velocity (here velocity is calculated as last 5 sprint average)
into 2. from the example below : Its calculated as current Velocity is 32. So to have a good healthy backlog you
should have at least 64 story points groomed and ready for planning. Where as per this example the backlog
has only 40 Groomed story. So the health of the backlog is 62.50%
Grooming efficiency
To calculate and measure the team’s grooming efficiency. The Scrum Master or any one needs to maintain the
record of each grooming session , Date , Number of Story points groomed and time taken for the session. The
record will eventually give you the trend of story points groomed per session and the grooming efficiency
based on the average. The example below explained how you can calculate the trend and efficiency by taken a
average of last 10 Grooming session. Its also help you to plan your future grooming to calculate how many
hours of grooming you need to achieve the 100% Backlog Health.
Post Grooming Activities.
After grooming there are couple of activities, Team can do as mentioned below

SCRUM MASTER CAN SEND A SUMMERY OF THE GROOMING SESSION TO THE TEAM AND INTERESTED PARTY.
The sample format can be like this
Team <Team Name> Grooming Notes
Date / Time : <Date> / <Time>
Duration: <Duration in Hour>
Attendees : < List of Team member attended>
Total Stories Groomed : <Count of Stories Groomed>
 Total SP Groomed : <Total SP Groomed>
Total Stories attempted and skipped : <Count of stories discussed but not groomed because of any incomplete
data or information, and parked for next groomed>
Next Grooming Scheduled : <Date and Time for the next Grooming if already schedules>.
Summary of Stories Groomed
Story ID Story Title

1 <Story 1 Title>

2 <Story 2 Title>

4 <Story 4 Title>

5 <Story 5 Title>

7 <Story 7 Title>

8 <Story 8 Title>

9 <Story 9 Title>

10 <Story 10 Title>

Total

Summary of Stories Not Groomed

Story ID Story Title Reason for not able to groom

3 <Story 3 Title> Mention Reason

6 <Story 6 Title> Mention Reason

Team needs to work on the parked story because of incomplete data or information

Scrum Master, Product Owner and the development team, can work on the stories to gather required
information or update cross functional team member, that the team may need their presence, on next
grooming session scheduled on so and so date.
Capacity Planning
What is Capacity Planning? How to do Capacity Planning (in Hours) When we should do Capacity
Planning? Benefits of Capacity Planning

6. What is Capacity Planning

Planning the Capacity means estimate and calculate the capacity of Agile team. There are two widely used
capacity measurement units
1. Story Points

This is Simple way to calculate the velocity (Average of last 6 to 10 Sprint’s Accepted Story Points). and target
the upcoming Sprint to commit the User Story that closely match with the velocity.
I Personally recommend the other way of doing the capacity planning by calculate it by Hours.
2. Hours

I personally recommend Capacity Planning by Hours. I will explain only on this way of Capacity Planning in this
Article. Its gives better visibility and accuracy. And many other benefits that we will discuss later in this article.
Here we Calculate the available bandwidth of the Agile Team (except PO & SM). By calculate their available
hours for the upcoming Sprint.
Will discuss in details about who to calculate it, what are Factors we should consider in this article.

How to do Capacity Planning (in Hours)

The technique is very simple to calculate & plan your capacity. I have explained below the steps to calculate it
manually. However in todays days all major popular ALM tools have that inbuilt, You just need to feed in the
details.
At the end of this article will show example of doing Capacity Planning in one or two ALM tool.
I have explained below step by step you can follow to do your capacity planning, even if you are not using any
ALM tool, just by maintaining an Excel.
Step 1 – Calculate Sprint Duration
Calculate the Sprint Duration in Days, Identify the Sprint Start Day and End Day. To explain this I have taken a
2 Week Sprint which Start on Wednesday and Ends on Tues day. And we are doing our Capacity Planning for
Sprint 2.
The picture in the right Represent a 2 week Sprint – Calendar, of 10 days. Spread in three Physical Calendar
Week. Through out the rest of the article, I will explain with this color legends , where
Yellow = Previous Sprint
Green = Current Sprint (for the Sprint we are doing the Capacity Planning)
Blue = Future Sprint.
Step 2 – Calculate Team Members Availability
Assuming We have 7 Members team 4 Developer and 3 Testers, Not Counting the SM and PO here, as we
don’t need to count their capacity in Capacity Planning

Step 3 – Identify Allocation %

Now Identify the Shared resource if any, If there is No shared resource, we will count every one is 100%
allocated to this Scrum Team. For example lets assume we have one Tester (Tester 3) who is shared between
two teams, and his allocation is 50% for this team in example.
Step 4 – Calculated The Standard Hours per day
If we assume every one has 8 hours per day on full allocation, The Shared resource will have 4 Hours per day
allocated for this team. For this sprint.
For 10 Days Sprint the total Max capacity is 520 Hours for the entire Team and having 52 Hours per day,
Including Shared Tester. Every One has 80 hours for 10 days and the Shared Resource with 50% allocation
have 40 Hours, for this sprint Duration.

Now Lets See how does that looks like in our calendar
Step 5 – Consider The Factors
1. Team Holiday
Mark the date that is off for the entire team. National Holidays etc.
2. Calculate the Individual working off.
Calculate based on – if any resource have planned off / out of office.
3. Override default working day hour.
If Required – Take an exception for individual team member, to change default hours from 8 Hours to some
thing else, Specially if some one has a plan half day or the plan hours have other than other than the default 8
Hours (100% Allocation)

Assuming – 9th of Jan is a Team Holiday

In this case : we can see from this picture, that the total and Individual capacity is reduced accordingly.
Assuming – Developer 1, Developer 2 and Tester 1 have a Planned full day off for three different days. By
applying that we can see from this picture, that the total and Individual capacity is reduced accordingly.

If Developer 3 plans a Half day work on 13th Jan. The plan capacity will change accordingly as below

Step 6 – Consider Other Work that eat up Times for every one
Consider the Time it will take for other meetings and Agile Ceremonies. The below picture represents typical
time a Teams Spends each ceremony and other meetings
Reduce 12.33 Hours from the Capacity

Step 7 – Consider Focus Factor

Plan it accordingly to your team can focus, for any unplanned time loss keeping in mind the daily time off,
adhoc unplanned meetings , other official activity, training, Discussion with SME etc. Remember for planned
activity your can still calculate before hand. We keep focus factor for any thing that can not be plan. That value
can vary 75% to 95%

So The Final Capacity for this Team for Sprint 2 is 318.32 Hours
Summarizing the 7 Steps

Please Note
The Values , Percentage and amount of hours are for the above example only. You need to put values based on
your own need and facts.
1. Calculate the Focus Factor the best suits your project.
2. Sprint Duration as per your Sprint Cycle
3. Plan it for Developers/ Tester and any other Role in your Scrum team (except SM and PO)
4. Team members allocation as actual in your team
5. Factors like Team Holiday, Planned Vacation, partial are not just limited to these tree factors.
6. Calculate the Times of Ceremonies as per your schedule with addition to any other planned meeting
7. In The above example I have not calculated the vacation day is falling under any ceremony day, to avoid
complication and granular level calculation.

When we should do Capacity Planning

With Scrum Master’s facilitation A Scrum Team can identify the capacity before the sprint planning. The best
time is just before the Sprint Planning for any specific Sprint, That gives the best visibility of Resource’s
vacation plan or Ceremony time.
If the Team is using any ALM tool, Individual team can update their available time, Scrum Master can help the
team understand how to calculate their Individual Capacity. Before hitting the Sprint Planning, the Scrum
Master can conduct a quick 30 min meeting with the team and get the Capacity Calculated and Update
accordingly. When I was a Scrum Master I used to calculate all the factors in Excel initially with the team 1 or 2
day before Sprint Planning, and eventually the team was mature enough to do that by their own with very
minimal intervention.

Benefits of Capacity Planning

Capacity Planning helps the team to gauge the available bandwidth for the team to commit and complete User
stories. Specially when you estimate your capacity by hours and map task of committed user stories with the
Individual capacity and his/her assigned estimated task hours. The team can identify the limit of committing
user story in Sprint Planning. We will discuss more in details how we map our tasks and capacity during Sprint
Planning, in a different article of Understanding Sprint Planning.
The Reason why I always prefer Capacity Planning and Mapping on Hours Rather than Velocity is, Its easy to
calculate available Hours by simply math with Days, Vacation, Leave, Other Time, Focus Factor etc. to get a
Team Capacity. That’s is technically not possible with Velocity and the team needs to make assumptions which
is dangerous,
Secondly you can not assign a Story (having Story points) to a single member, as completing a story is mostly a
team effort. And distributing any story points between team member, Huh!! Cant even think about it, where
One Story (what ever the story point is) can have multiple tasks (each task having efforts estimated in Hours)
can easily be assigned to one or more Team Member, each task can assigned to each member. We will see
more in details with demonstration in a different article of Understanding Sprint Planning.
 7. What is Sprint Planning
In Scrum, we have multiple time boxes called Sprints or iterations. In each Sprint bunch of functionalities in the
form of stories are implemented to make incremental enhancements to the product under development. The
Sprint Planning meeting is the kickoff meeting for each Sprint. This meeting helps set the context of the sprint
by scoping the product owner goals for this sprint. It also prescribes the priority for the stories, based on
available bandwidth/capacity to meet the goal and deliver the incremental value to the product.

Who Should Participate in Sprint Planning Meeting

Scrum Master facilitate the Sprint Planning meeting, during the sprint planning meeting, Product Owner and
the Development Team agrees to the Sprint Goal, and negotiate which item from the product backlog will be
committed to the sprint backlog.
Generally the scrum team use to have the product backlog items estimated (story point) earlier during
grooming season, if not or in case product owner wants to have some non groomed story to be included in the
sprint, the development team can groom and estimate the story during sprint planning.
Also in this meeting the Team will come up with initial list of tasks necessary to complete the committed PBI
(Product Backlog items), with estimated effort in hours.
So who should participate in Sprint Planning meeting ?
1. Product Owner
2. Scrum Master
&
3. Development Team
In rare situation Stake Holders or other business sponsor can also attend by invitation from scrum team.

Lets take a quick look on Scrum roles and their responsibilities for Sprint Planing Meeting.

 Verify the Sprint Goal is meeting from the stories committed by the scrum team
SCRUM ROLES RESPONSIBILITY BEFORE SPRINT PLANNING

SCRUM ROLES RESPONSIBILITY DURING SPRINT PLANNING

SCRUM ROLES RESPONSIBILITY AFTER SPRINT PLANNING

Prerequisite of effective Sprint Planning Meeting.

We already learned what is sprint planning and who can attend the meeting with what responsibility. Now
before jump into start the sprint planning lets quickly have a look on the prerequisites of the sprint planning
meeting.
Prerequisites of Sprint Planning Meeting
1. Prioritized Backlog

We will talk about details on Product backlog on some other article. For sprint planning we need to have a
product backlog, where the Product Backlog items (PBI) are arranged in priority. The product owner may do
the prioritization during sprint planning, but the prioritization is mainly a product owners activity, to utilize the
sprint planning time with interest of every one, I always advice the product owner to prioritize the PBIs before
sprint planning.

2. Groomed Stories

Many Agile team utilize the time of sprint planning to groom PBIs. I have explained, why a team should groom
their stories before sprint planning at the article of backlog grooming. So I always coach the agile team to
groom the product backlog well in advance of sprint planning. to have the PBIs well elaborated in details,
estimated (Story Points), have the Risks and dependencies identified.

3. Definition Of Ready.

I will cover the details of Definition of Ready (DOR) in details in a separate article. Assuming you all know what
is DOR.

Its a good practice to have a team DOR defined (subject to modify), The team always refer the definition of
ready during sprint planning, before committing a story for the sprint. If a particular story in priority, and the
product owner wants to have the story, part of the sprint to meet his this sprint goal, It has to pass through the
DOR gate. DOR are the check list points to define the entry criteria of any user story if it is ready to commit or
not.

4. Planned Capacity

Teams capacity to plan a sprint can be mesured by two different way,

1. Story Points (Average Velocity of last sprints)

It can be used for a stable team, with no change in team composition, No variation of team members
allocation sharing between projects.

2. Hours (Available bandwidth of the team for the upcoming sprint duration)

I always suggest to plan your capacity based on Hours, keeping in mind the team member’s allocation %,
Vacation, Holidays, time for Scrum Meetings etc. and get the available capacity for the sprint. To Learn details
of Capacity Planning visit the link – of Capacity Planning .

Having the capacity defined, will help the team to commit right amount of PBI from product backlog to sprint
backlog. Will learn details about the sprint planning and using the defined capacity later in this article.

How much time should Sprint Planning Meeting take

As per book, the sprint planning meeting should takes 2 x (number of weeks in sprint) Hours. Means if your
sprint is 2 weeks your Sprint Planning meeting will take 4 Hours, if its is of 3 Weeks your Sprint Planning should
be 6 hours and so on.
But in practical practice of each team is different, We are maturing our agile practice and improving the way
we started running our agile framework. So the time the sprint planning takes depends upon our practice and
our agility of managing works and time.
As per book, if it says we need 4 hours to complete our sprint planning for 2 week sprint, lets first try to
understand what is expected from that 4 hours.
1. Product Owner to define the Sprint Goal, and get it Negotiated with development team.
2. Identify Stories to meet the goal, or create new stories to meet the goal
3. Groom the stories, Understand Requirement, identify dependencies, identify risks
4. Estimate (story point)
5. Plan team capacity (If capacity not measured as velocity)
6. Break down into tasks, assign tasks, estimate Task hours

And if you really doing all those activity, it will take that much of time.
How ever in situations, teams may practice of having few of the activities prior to sprint planning, resulting less
time consumption at sprint Planning. Lets have what are activities can be achieved earlier.
 Product Owner to define the Sprint Goal
 If Product Owner have a clear vision, he might have the goal defined earlier, Product Owner should not
define the goal based on committed story, that will become formality of having the sprint goal. If the
Goal is already defined, PO only need to discuss them with the presence of Scrum team and make
everyone aware of the expectations. by doing so the team will save time from sprint planning meeting.
 Identify Stories to meet the goal, or create new stories to meet the goal
 Prioritization is important, if the PO keep the backlog prioritized based on expected sprint goal,
associated risks, and business demand, The team can save time on identify user stories to pick from
product backlog
 Groom the stories, Understand Requirement, identify dependencies, identify risks
 Many teams have, and I personally advise to have grooming once or twice a week, to have a healthy
backlog, by having Groomed story as twice of velocity. That saves lots of time and resolve uncertainty
during sprint planning.
 Estimate (story point)
 Its always better to have story points estimated for all the groomed stories, you can estimate the user
story during grooming, and can have a check point of your definition of ready. And yes it will definitely
save time from sprint planning meeting
 Plan you capacity (If capacity not measured as velocity)
 If Capacity not measured based on velocity, that means it has to be calculated based on hours. So if the
development team have the capacity planned before sprint planning. its will save time.
 Break down into tasks, assign tasks, estimate Task hours
 This activity will do during sprint planning meeting. Many team does this activity partially or fully after
sprint planning. I suggest to have this activity during sprint planning.

So how much time a sprint planning should take, its depends upon your practice. It can take 1 to 4 hours for a
2 Week Sprint. The teams I coach, after 2 to three months of practice they come down to 1 to 1.5 Hours of
sprint planning for 2 weeks sprint. Remember the earlier section ? Prerequisites ? Yes If you want to optimize
the time of sprint planning, you need to have the prerequisites ready.
Now if you are thinking if all those activities we are doing before sprint planning, what we will be doing during
sprint planning. That we will learn in this next section.

Step by step walk through of Sprint Planning Meeting

Yes sprint planning is one of the core ceremony to plan your sprint scope. Before we jump into granular details
of sprint planning lets first try to understand where sprint planning ceremony is placed in scrum workflow.
Refer the below picture of a scrum work flow. As Agile is a framework, there may be slight difference on the
work flow, you are working or may work. However basic structure remains same. In this work flow, you will be
able to identify ongoing activity and prerequisites for sprint planning.

Now from the below picture lets find out where are those prerequisites stands, for the sprint planning meeting
with in scrum workflow.
The prerequisites of

 Definition of Done
 Groomed and Prioritized backlog
 Planned Capacity from capacity planning
is shown providing inputs to the sprint planning.
Before we jump into step by step activity we do in sprint planning, lets have a quick look at the outcome of the
sprint planning meeting. Refer the below picture to understand the output of sprint planning meting.
Those are
1. A Sprint Goal.
2. A Sprint backlog.
We will talk about the details of this out come, later in this article under “Expected deliverable of Sprint
Planning Meeting” section.

Lets now talk about what we do with in sprint planning meeting. Step by Step each activity we will talk about,
and then will see in a diagram how all the activity are linked together.

The Sprint Planning meeting generally have two main areas,

1. Defining the sprint Goal
Sprint Goal is a target or objective for a sprint. Which can be achieved by implementing set of functionality
( PBI, user stories, Bug fixing etc.). The Development team and Product owner negotiate and collaboratively
set up a goal for a specific sprint or iteration. The Goals is better to be measurable. The selection of the
Product backlog Item from Product Backlog is depend upon the Goal. Sprint Goal should be short, 2 to 3
sentence.

2. Defining the scope of Sprint backlog

The Second half of the sprint planning is spent for defining the sprint scope, keeping in mind the sprint goal.
lets see the step by step activity below to identify the sprint goal.

Selecting the Product backlog item from product backlog

The first step to define the sprint goal to have a sprint backlog, the team selects the first product backlog item
from the prioritized backlog. Selection of this story/PBI is a part of sprint goal fulfillment.
Product Owner selects the PBI from backlog with teams consent.
Make Sure the PBI is ready to commit
Ideally the picked up PBI are in groomed state, where the dependencies are mapped, and communicated to
cross functional team, Risks are identified, Story point estimated. And requirements are mutually understood
by development team. And the PBI is in a position to meets the definition of ready.
However, there are possibilities, that product owner identified some stories that needs to be done by the
upcoming sprint. And that PBI yet to be groomed and needs meet the Definition of ready to be committed for
a sprint.
In that case, The team groom that specific PBI, Check their dependencies, Risks, feasibility, and estimate its
relative size in Story point during sprint planning.
If the PBI was already groomed and estimated, teams move to the next step.

Task Break Out

Once the picked up PBI meets the definition of ready, the team starts working on task break out. the
development team creates multiple sub tasks against the PBI, keeping all possible technical works needs to be
done, like development, Testing, code review, QA deployment etc. create as many task you think will be easy
to manage.
There are debates on how many tasks we should create, many agile practice says, keep it simple by just having
3 tasks, 1. Analysis, 2.Development, Testing.
Where many agile practices says, keep the task as much you want to have the work transparent and visible.

Task Assignment
Next, the team collaboratively assign the tasks to development team member. A self organized team can
assign the tasks to team selves. Its best to have all the team member are of same technical expertise level, but
in practical situation its very rare to find a time like that. So the team finds which task is suitable for which
team members skill set and expertise level. And assign it accordingly.
The Scrum master and the team always keeps an eye on the capacity, to avoid any kind of over allocation, that
may risk the sprint with unfinished work.
Task Estimation
Once the task assignment is done, its time to estimate the task. As each team member my have different skill
set and experience level, its always better to have the task estimation after assignment to individual.
This estimation is effort hours.
If the team is new its advisable to have tasks hours to keep with in 8 to 12 hours. This helps the team to
analyse in details and give better transparency. The Team can create new sub-tasks, or split existing sub tasks
into one or more.
Remember to update the capacity tracker with the hours and team member. That will be useful during your
next PBI commitment. If you need to understand details of capacity planning. Please refer our another article
on understanding capacity Planning.
Note
Agile is a framework, the above mentioned was is one of the best practice of running scrum, many team have
practice of not estimating or creating sub-tasks during sprint planning, rather the do it after sprint planning,
may be during next few days. And they are doing perfectly fine.
But they may not be able to plan based on capacity, and may have fluctuations on Scope creep and
commitment reliability.
I always suggest to have the tasking during sprint planning, so that you can utilize you capacity in optimum.
You will able to produce yourself a good and healthy team during metrics reports at higher level.

Commit to the sprint

And then finally add the story to sprint backlog.
and proceed to the product backlog to pick the next PBI to plan.
And continue this step till the time planned capacity is fully utilized. It may be possible there are stories left in
the backlog and your capacity is fully utilized, and that’s normal. Check you goal how much its covered from
the committed sprint scope. Now you can make minor modification on the goal to represent the commitment
and Goal in sync.
Similarly it may be possible that all the stories are committed and still there are some capacity remains. The
team can pick some intangible PBI or technical spikes or non user story to fill up the gap. To understand more
about types of Product backlog items or User story. Please read the article on Understating User story.
There are other situations like, in case the team ratio is 70% developer and 30% tester, where during planning,
the tester’s capacity is filled after certain PBI commitment. In that case also, the developers can pick technical
spikes or utilize their capacity on testing tasks.
Refer below the full diagram of Sprint planning.

Expected deliverable of Sprint Planning Meeting

Sprint Planning meeting have two parts, first half the team define the Sprint goal, and then at the second half
team define the Sprint backlog , the scope of the sprint to meet the goal.
So the two deliverable from Sprint Planning meetings are
1. Sprint Goal
2. Sprint Backlog
Lets find out little more details on these two artifacts.

Sprint Goal
What is Sprint Goal
Sprint Goal is a target or objective for a sprint. Which can be achieved by implementing set of functionality
( PBI, user stories, Bug fixing etc.). The Development team and Product owner negotiate and collaboratively
set up a goal for a specific sprint or iteration. The Goals is better to be measurable. The selection of the
Product backlog Item from Product Backlog is depend upon the Goal. Sprint Goal should be short, 2 to 3
sentence.
Benefits of Sprint Goal
The Business Sponsor or stakeholders, prefer to get a vision from a birds eye view, rather than details story
level information. The Sprint goal is always better to highlight what the team is doing. And at top level, if they
are managing multiple teams, 2 to 3 line summary from each team is a useful information.
The team commit to a goal and associated PBIs, that helps the team to execute the sprint with a specific vision.
Importance
During Sprint review, product owner, or stakeholders, verify the product increment by comparing the Goal and
how much is achieved. That’s defined the success of the sprint.
Example
1. Implement the Login screen functionality
2. Implement the functionality to enable Credit card payment on shopping cart.
Sprint Backlog
Sprint Backlog is one of the artifacts of Scrum. and its get generated on every sprint planning, and is a active
for the sprint duration. After the sprint ends this artifacts gets closed and only refer to reporting purpose.
Sprint backlog contains Product backlog items committed for a sprint. means if you are doing a sprint planning
for Sprint# 12, all the product backlog items committed for Sprint#12 will be under sprint backlog #12.
Each Sprint will have a sprint backlog, and it may contains User stories, Bugs, Spikes etc. The Sprint backlog is
virtual list of bunch of product backlog item, you may able to see it as a list of items in your ALM tool. During
the beginning of Agile era, Agile teams used to maintain one big excel for product backlog and independent
excel for sprint backlog (Many Agile practices still follow this excel). Now a days the ALM tools like Rally, Jira,
TFS, Version one etc have made our life easy to manage all those numerous sprint backlogs easy to manage
and track.
Don’t mixed up Burn-down chart, its not a part of sprint backlog, its a part of your sprint.
Don’t mixed up with Scrum Board or Sprint Board with Sprint backlog. This Boards are visual representation of
the sprint backlog Items with their status.
Sprint backlog have, Sprint backlog items. You can calculate aggregated values like

♦ Number of Items

♦ Total Backlog story points (size of the backlog, calculated by total story points of all the Items).

♦ Total backlog story points at each stage , for example, How much SP in ToDo, how much in Analysis, how
much in Development, how much in Testing and home much are Done.

♦ Total estimated effort hours (Tasks estimated hours for all the tasks of all the stories)

♦ Or Total remaining estimated effort hour

Summary report of Sprint Planning

Once the Sprint Planning is over, the Scrum Master sends a Sprint Planning Notes to everyone including the
Scrum team and other interested members like, Stake holders, Project Managers, Business Sponsors etc.
The Areas you can cover in a sprint planning notes are as below.
1. Sprint Goal
 Highlight the agreed Sprint Goal
2. Sprint Duration
 Mention the Sprint Duration in Days
 Sprint Start Date
 Sprint End Date
3. Sprint Schedule
 Mention all the sprint ceremonies like Demo/Review, Retrospective schedule
 Attach the retrospective links (if possible), so that people can start their ideas when ever the feels like.
4. Capacity Utilization
 Give a capacity summary
 Optionally you can also attach the details capacity utilization, with Team members name, Story id and
Task Hours
5. Commitment summary
 Give a Summary of your commitment
6. Commitment Story Summary
  Mention the story details those were committed.
Refer the image below, click to see it on a larger size, You can refer the image to create your own Summary
report as per your need. The data provided in the report are just an example only.
Benefits of Sprint Planning Meeting
Sprint Planning is the one of the core ceremony of Scrum. If you have went through this far of the article you
might have realized the importance of Sprint planning meeting.
I am summarizing the high level benefits of sprint planning meeting, here below.

Goal Visibility.
To work on something, we need a target, a goal to work on. The scrum team gets that target as sprint goal for
a limited time box or for the sprint. Having a goal for the team gives them the visibility why we are working on
this stories or product backlog Item.

Scope Visibility.
Scope (The committed User Story or product backlog item) is very important to define for a limited duration of
work, As we already have the goal. The definitions of the scope give the team what to work on to meet the
goal. Having a clearly defined scope, helps the team to focus on their action item, plan of execution and on-
time completion

Task Discovery
On Granular level execution of scope, Task break down helps to pin down the activities and plan individual
level To-Dos. Sprint Planning meeting helps the team to have the necessary ground level tasks against each PBI
or User story, Have the Tasks estimated in hours and the Tasks assigned to individual team member. This gives
a great visibility , and transparency on individual level as well as on team level to focus, plan and execute the
work items.

Optimal usage of capacity

Scrum Team have a limited capacity for each iteration/Sprint/time box. To use the capacity in most optimized
way sprint planning meeting facilitate the distribution of tasks to individual. which helps the team to avoid
bandwidth wastage and over loading. Resulting high performance and quality product.

Improve Team Collaboration

And finally this Sprint planning meeting involves all the scrum team members, along with cross functional team
and Stake holders. That improves team collaboration and a healthy productive environment.

Improve Commitment Reliability

Sprint Planning helps the team to commit based on their capacity, resulting the team save themselves
from over commitment. That in result improve their commitment reliability.
Control Scope Creep
Sprint Planning helps the team to commit based on their capacity, resulting the team save themselves
from Under commitment. And so the team don’t need to add additional PBIs in their sprint scope, and the
team remain on the commitment of initial scope definition.
What is Sprint Review Meeting Participants Duration How it Works Outcome Post Meeting Activity Video

8. What is Sprint Review Meeting

Sprint Review Meeting also known as Sprint Demonstration usually held on the last day of the sprint to
demonstrate the accomplishment from the specific sprint commitment. Product Owner from many Agile
practices, also review the completed story and mark them as Done or Not Done based on “Definition of Done”.
This Meeting is the realization phase of the each sprint cycle.
This is an Informal meeting, No need to prepare Power point slides or any presentation.

This meeting also supports Agile framework as Empirical Model, by Inspect and Adapt. Inspecting the Product
Increment and Adapt the Product Backlog.
There is no defined rules for this meeting, But the meeting has to happen during end of every sprint to have
the green signal from the Product Owner or stakeholder for the potentially ship able increment, which was
constructed during the sprint.
Participants of Sprint Review Meeting
Though the Scrum Team Members are the only participants of most of the Scrum events, but at Sprint Review
the team needs the stakeholders or Business sponsor or Management to showcase the sprint increment.
For this meeting the key stakeholders, Business Sponsor, Management Participates, Those group of people are
not fixed for every sprint. Based the scope of each sprint, the participation from management or stakeholder
may change.
The Product Owner Invites the key stakeholder in advance. As Product Owner is the bridge between the scrum
team and stakeholders or business sponsor, PO is the best person to send the invitation. The stakeholders or
Business Sponsors or Management or Customers are the key Recipient of the meeting. And it’s not a one
person, most of the time it’s a group of people from different business area.
The Team, primarily the Scrum Master Facilitate the meeting, Schedule it in advance, and set the Scope of the
meeting (Explained in details in the next section). Product Owner Cascade down those information to Primary
Recipient of the meeting to review the increment (The Stakeholders, Business Sponsor, Customers,
Management). So that the Key Recipient can take a decision how important for them to attained the meeting,
and may choose to opt out.
The Development Team demonstrate the stories one by one as planned. Or can change the sequence on
Product Owner request or on key meeting recipients request.
The Stakeholders review the increments, Accept increment(s), suggest new changes for future sprint, or reject
the increment (Partially or fully) to be deployed.
Time Box of Sprint Review Meeting
Sprint Review Meeting is an Informal Meeting, The team don’t need to present any power point presentation
of go-through slides. Here the team demonstrates the stories/bug fixes/ technical spikes etc they have worked
on through out the current sprint (or just finished sprint). And Stakeholders explains visions and expectations
from the team as future sprint deliverable s. Typically the time takes to complete the meeting is 1 Hr per
week of the sprint duration. what that means is, if a sprint is 1 week long, the team can complete the meeting
in 1 hour, where 2 week sprint takes max of 2 Hours and 3 week sprint takes max of 3 hours.
On an average, majority of the sprint review meeting can be concluded in 2 Hours.
for the initial sprints, It may take little longer, as the team is learning about this events, The coach keeps on
training the participants about the events and best use of scrum values, keeping in mind the Empirical Model
to implement the Inspect and Adapt. And later the team become more mature and learned to optimize the
time for each event including sprint review.
The duration is not have any strict rules. It may be finished early than expected or scheduled, depend upon
what are the scopes of demonstration. If the entire scope of the sprint deliverable is demonstrable (functional
increment), it may take more time, compared to a team works on functional increment mixed with Technical
spikes and bug fixing. Technical Spikes are most of the time not demonstrable to key stakeholders, hence the
overall sprint review in this case will take less time as the sprint have less functionality to demonstrate than
the team can do.
Secondly apart from functional demonstration, how much time the team spend on Introduction, Creating new
Backlog Item as key stakeholders request, how much time the team spend Re-prioritization product backlog
item also influence the total time for the sprint review.
So don’t stick to the duration, Target for 2 Hours, but getting the objective of the meeting fulfilled is
primary, it may take little more or less time.
1. Get all the functionality demonstrated, and Accepted by Product Owner.
2. Identify New Backlog Item (if any)
3. Re-Prioritize Product Backlog Item (if required).
4. cover all aspect to close & conclude the sprint and get ready for next sprint planning.

How Sprint Review Meeting Works

The Sprint review meeting is not only a meeting for demonstration, its more than hat. Its an informal meeting.
All participants can get together with Tea/coffee and get the advantage of being co-located, If the agile team is
distributed, they can join the meeting on Phone or over screen sharing bridge.
Though many of us believe to get the formal acceptance of our sprint deliverable from key Product Owner in
sprint review meeting. This is not the meeting for story acceptance for any sprint. Product Owner as a part of
scrum team member, works closely with the development team, and during the sprint execution stories get
verified and accepted by product owner as on when its ready and meets the “Definition of Done”.
So It’s not only a formal sign-off meeting based on demonstration. Let’s learn how we can conduct this
meeting and its details.
Scrum Master is the local coach for the team. He/she needs to make sure it happens and everyone follow the
process properly.

Starting the Meeting – Welcome, Introduction & Set the Context Ready.
Ideally Product Owner starts the conversation by a quick welcome mes

sage to all participants. Followed by a

casual and brief introduction between new participants. There may be new stakeholders or business sponsors
join the meeting for first time and at the other side the development team can have new team members. It’s
always good to have a quick introduction between all the new participants. Mentioning the information about
who’s who and how he/she is involved with is sprint development or Sprint value or deliverable.

As Product Owner is the bridge between new the Scrum team and key stakeholder
or business sponsor or end user, Product Owner takes this initiative and roll the ball to start the sprint
Review meeting.
Product owner also give a quick explanation on how the team will perform the Sprint review with some basic
rules (if any).
Highlight the scope of Demonstration
It’s always good to have awareness of the scope or agenda of any meeting before attending it. For Sprint
Review meeting also Product Owner mentioned the details of the functionality that will be demonstrated, and
some other changes the team has made but not planned for any demonstration, or may not be demonstrable,
like technical spikes or discovery story.
It’s a good practice to circulate the sprint review demonstration scope for each sprint, 1 or 2 days in advance
to product owner. This can be done by Scrum Master or Product Owner. I personally suggest to have this work
done by Scrum Master.
This helps the Stakeholders to decide whether to
1. Join the Review Meeting
2. Not to Join the Review Meting
3. Invite other Management people or Business Sponsor or additional stake holders
There are many ways of circulating the information. Based on my experience I suggest to work on the
communication little before than the sprint end. Follow the picture below to understand it better. Where I
suggest to have the Scrum Master sends the communication as a form of list one day before the sprint last
date to the scrum team including PO, with a prediction of the next day accomplishment.
On the last day, PO confirms the list and invite associated stakeholders by sharing the list as a heads up.
The same list PO also reiterate at the beginning of the sprint review meeting.

Below attached a template you can use to articulate the scope. It has a list of all sprint backlog items, in a
sequence it will be demonstrated (however items can be demonstrate on different order on stakeholders
request). The sprint backlog items can have its parent item like feature or epic, that helps categorize the list
which increase the readability as per stakeholders interest.
You can have the list based on your team feels is best, keeping stakeholders interest in mind. The columns in
image below are self explanatory. The Last column “Will Demonstrate” is to gives a head up that, though the
item was part of the sprint backlog, Its plan for not to demonstrated, there can be three main reason for not
demonstrating.
1. The work item have not completed in constriction or testing and will not be ready for demonstration.
2. Its a technical spike or discovery story. And nothing is demonstrable.
3. The work item is not so important to demonstrate.
How ever stakeholders can request of those item during sprint review to demonstrate.

Demonstrate the new functional Increments

This is the main part of the meeting, where the functionality increment gets demonstrated by the scrum team.
There is no strict rule who will demonstrate the story. Product owner or development team member can
demonstrate the functionality. Its not necessary one person has to demonstrate all the functionality, it can
rotate to several team members. The team experiment sprint over sprint and intelligently figure out the best
way to select the person for demonstrating.
Many agile practice have the demonstration for functional increment as their only agenda of sprint review
meeting. However there are other important aspects of this meeting, we will learn later in this article.
The demonstration usually happens in a close room with a projector, projecting the screen of demonstrator.
Now a day the agile teams are become more distributed, where gathering in one room is practically not
possible, however in situations like this, it can be done through screen sharing using any meeting collaboration
tools like WebEx or Skype or goto meetings or blue jeans.
The primary goal of the demonstration is to gather feedback from stakeholders or business user to improve
quality, discover new product backlog items and directions for future sprints deliverable.
Business Users or Stakeholder may request to demonstrate additional functionality, which may not be the part
of current sprint. Those out of scope functionalities use to have relation with the current functionality getting
demonstrated. The Team take a quick decision and demonstrate the requested additional functionality.

Discuss Future Sprint Scope

After completion of the demonstration, Product Owner gives a quick summary of current backlog items for
next sprint, just to keep every one on same page. This can be done by a quick presentation.
Many times stakeholders discuss about their long term and immediate visions and expectations from the
team. That can be covered in next couple of sprints by the scrum team and increment the product
functionality to meet the Business User or stakeholders vision or goal.
The Product Owner is well aware of the current backlog health and its clarification maturity. The Product
Owner can express that he/she needs further clarification offline from the stakeholders to mature up the
backlog and requirement clarification keeping the business vision in mind. That meeting happens outside of
the sprint review meeting.

Identify New Backlog Item

After the discussion on product vision and immediate expectation from the team , compared with the available
product backlog items. The Product Owner may identify new backlog items needs to be created.
The Product Owner or the team don’t need to add those items in backlog then and there. For the interest of
every one’s time. The PO along with Scrum team makes the Action item to create new user story, prioritize ,
groom and plan for best possible future sprint.

Re-Prioritize Backlog Item

The functionalities or features identified for future execution, currently at the bottom of the product backlog
with low priority, can get high priority based on market condition or business strategy. and vice versa, The
stories planned for next sprint or near future, may gets a hold on signal due to the same reason of Market
strategy or any other.
The Stakeholders / Business users / Business sponsors may takes the decision and re-prioritize the backlog
items to plan for upcoming sprints.

Conclude the Meeting.

Now its time to wrap up the meeting. Few good practice you can follow to wrap up the sprint review meeting.
1. Quickly summarize all the discussion points and action points (5 to 10 Min Max)
2. Consider a “thank you” to all participants.
3. You can also consider a little extra time to appreciate one or two team members, about their great work
and contribution.
4. Remind every one to participate the retrospective meeting to improve the agile process. (Sprint Review
and retrospective are two different meeting)

Potential Outcome of Sprint Review Meeting

The Sprint Review meeting is primarily establish a feedback loop for any scrum team. Which always helps the
team to improve on quality, process, and value.
There are many direct indirect benefits and outcome of sprint review meeting. I mentioned below most of
them.
1. Increment Inspection & adaptive backlog: to support the empirical model of agile inspection is very
important, here in this meeting, the functionality increments gets inspected, result to a adaptive product
backlog.
2. Improve Collaboration: The team get chance to interact with business user and stakeholders, that
motivates the team and increase the visibility on the product they are working on.
3. Transparent Business Vision : The team get familiar with the vision of the business user and the gets more
clarity of the result of the the work they are doing or about to do
4. Up to date prioritized Backlog : Re-prioritization helps the team pick the best story for the sprint, that will
create the maximum value to the product and business.
5. New Backlog Items : This meeting may hatch new product backlog item, to cater with dynamic market
trend and competition.
6. Team Motivation by Appreciation : Praise of team member by Name motivates the team. and a motivated
team always good for self organization and best output.

Post Sprint Review Meeting Activity

Once the Sprint Review meeting is over, Its a good practice to do few activities like as below.
1. Meeting of Minutes : Its always a good practice to send a meeting summary, Scrum Master can circulate a
meeting of minutes to all participants and also to the person invited or involved but unable to attend the
meeting. The summary can include, All story demonstrated, New Backlog Item Introduced, the change in
business vision if any. The details of new priority, mention the team member appreciated and for what.
2. New Backlog Item : Product Owner to create user stories in product backlog. and based on the decided
priority reorganized them in backlog. If those stories are on immediate need, Scrum Master can schedule a
adhoc grooming session, to mature the requirement, and team can estimate the size.
Generally its use to be the next day scheduled for sprint planning meeting, so if there are some
functionalities identified for the next sprint, those functionalities must be available with all necessary
details to meet the “definition of ready” as a form of user story in Product Backlog. So that it can be
commit in sprint planning meeting next day.
3. Re-prioritize : In case of some stories got higher priority as a result of sprint review, those stories may
needs grooming to meet the “definition of ready” to plan for next sprint. and also needs grooming.
4. Sprint Closure Report : This is optional and not directly related with sprint review meeting. Ideally sprint
review meeting happens as a last ceremony of the sprint, some times after Retrospective meeting. So its
always a good practice to collaborate your sprint accomplishment as closure report, once your sprint and
all its associate ceremonies are over. I will explain on all the Agile reports on some other article.
 9. What is Sprint Retrospective Meeting
Sprint Retrospective the one of the important ceremony of your sprint cycle, Its usually very common on
Scrum framework, many teams also conduct this ceremony for their Kanban practice on a regular interval.
Generally this meeting takes place after sprint review meeting and before the sprint planing of next sprint. If
you want to conduct your meeting for your kanban cycle, you can define a interval like every 15 days to
schedule it.
This meeting enables the feedback loop to achieve continuous improvement. No matter how mature your
team is, opportunities of improvement is always there. This meeting gives the freedom to all member your
team to speak about what they feel can be improved, or what they feel can be stopped. This meeting also
enable the empirical model by inspecting the process from transparent input and adapt opportunities of
improvement.
The main difference of sprint review and retrospective is, Sprint review talks about the achievement, upcoming
works for the functional increments, more about the product. where retrospective highlights more about the
process like. “Resolution of cross functional dependencies” can be improved, “On-time joining on daily stand-
up can be improved”. etc
We will talk about details about, How we can conduct Retrospective, Different ways of Doing Retrospective,
Tools you can use to do your retrospective, how to capture and work on the action item of retrospective.

Participants Sprint Retrospective Meeting

As we already learned that this meeting is to inspect the as is process practice and identify the improvement
areas. Its always better to have the Scrum teams (SM + PO + Development team members) presence.
There is no harm on getting the feedback from external team members like cross functional Team your
Integration team, even your stakeholders and business sponsor can also participate to provide their feedback,
ideas to improve your practice and opportunities to adapt the best suitable practice for the team.
Its all depends upon your team’s relation and association with external team members and their
participation’s.
For example, if you are working with the user stories those are highly depend upon another team like your
team needs to have some functionality developed, where a Data Definition Language needs to altered. Due to
the big complex product, organization have centralized a cross functional team (Lets “Team DDL”) for
managing any kind DDL changes. The Team DDL have their own scrum or Kanban flow, they work on based on
the priority from other product owners. Your team needs to have a very good synchronization with “Team
DDL” to resolve any kind of dependencies your sprint have. During the retrospective input from “Team DDL” or
Your input to “team DDL”’s retrospective may add values to improve the work practice for both the team.
If there are multiple scrum team working for one big product, Its need to be integrated code increment from
all the Scrum Team before deploy to a next stage (example System Demo). You code may directly or indirectly
relate to code from other team. So synchronization in important, and Retrospective action item to improve
synchronization always better.
Involvement of external team member is absolutely Optional. But presence of Product Owner, Scrum Master
and Development team member is very much required.
No Matter you are working on a Product Based company or Service Industry, Your Product Owner or Scrum
Master are from Client side or Same Company. Product owner, Scrum Master and Development team are One
Single Team. Mutually you can inspect and adapt for betterment.
Similarly Scrum Master keep all the participants engaged, facilitate the meeting and make sure the meeting
happened, and protect the agile process.
At the same time, if you are involving Other team member mainly from Management or stake holders and
Business owners, there are very high chances of deviating for the agenda of the retrospective. You need to be
very cautious to stick to the Retrospective agenda.
As Agile an Empirical Model, with the pillars of Inspect, Adapt and transparency. You can have the
Retrospective within your Scrum team only and later shared the Action items and Retrospective points to all
management and cross functional team. In Practical Its little hard to change others, but you can change and
adapt yourself to perform better with the external constraints.
In few situations You may face product owner act as a manager, or commanding member, which is not correct.
Please take help from your local coach to get the situation handled.
One Important Point, irrespective of participation from Scrum team, cross functional Team, Management etc,
the Inputs has to come anonymously, to give freedom of speech and solution will be planned mutually.
Will learn more about the process of doing retrospective techniques later in this article.

Duration of Sprint Retrospective Meeting

Again this meeting down does not have strict time boundary. You need to optimize the usage of the time,
focus on the primary agenda of the meeting to inspect and adapt. will talk about what and how you can
conduct this meeting to get the benefit of Retrospective.
There are couple of events you can do during retrospective.
1. Gather opinion of good and bad practices from the participants
2. Prepare Action items to improve your practice
3. optionally you can play some agile games, Quiz etc to build team moral and bonding.
which typically can take 1 Hour, it some time can take some little more time. The time does not varies on the
sprint duration, 2 weeks sprint, 3 weeks sprint or even 4 weeks sprint does not influence the retrospective
duration because of the sprint length. As the number of retrospective areas remain same. However the time
can varies on below mentioned points.
1. Team size (less team member may have less points compared with big team size.
2. How new the team is on Agile Process (as its team may need coaching to learn the process during the
retrospective.
3. Controversy on he retrospective points
4. Conflicts on preparing action Items, and assigning the action items.
5. Team building activity like quiz or Games.
6. participation of external team member.
You can plan you retrospective for 1 hour 30 min, if you are new to the scrum, once you get matured you
can bring it down to 1 Hour.
You can further save time by using various tools (I will explain it later in this article) to gather inputs from team
members in advance.

How to run the Sprint Retrospective Meeting

Sprint Retrospective is the last ceremony of every sprint, Please refer the picture to understand the position of
retrospective at sprint life-cycle.
Now lets talk about the ways you can conduct this ceremony to get the best out of it.
There can be two different team distributions collocated or distributed. You may be part of a distributed team
or a collocated team, in both the cases this ceremony is equally important.
For Retrospective we need to gather inputs from Scrum team members and from the team you think your
team work is related to. We should try to get the information anonymously, to increase the freedom of
speech, and get the opportunities of getting maximum inputs.
The collection of information
For a co-located team the meeting can conducted in a closed room with a whiteboard, the information can be
come from individual on sticky notes, each sticky notes should have only one
points/appreciation/concern/suggestions, you may use multiple sticky notes for multiple
points/appreciation/concern/suggestions. Every participant can write their points with in meeting during
starting of the meeting. Or they can keep the sticky notes ready before the meeting start. I always suggest,
keep on writing all the points of retrospective, as soon as it comes in your mind, it may possible you may have
forgot the points that was on your mind on the first day of the sprint. As this ceremony is the last ceremony of
the sprint and conducted on the last day of the sprint.
for a Distributed Team the collection of the retrospective points can be collected with the help of retrospective
tools over the internet. There are many tools available over the internet for free to do your retrospective, I will
talk about couple of them later in this article. Using those tools the team members can add their retrospective
points electronically at the digital retrospective board.
Adding Retrospective points/ideas to the board.
For distributed team using the digital tools the Retrospective item cards will automatically appear on the
retrospective board. Many co-located team also use the digital board for easiness. However the collocated
team can draw the board on any white board and start putting the sticky notes at the designated area of the
board.
Understanding the Board

Let’s understand the retrospective board. There are many ways of structuring the retrospective board, I will
discuss 3 of the most popular way of preparing the board. Also known as Retrospective Techniques.
1. Simple Retrospective
2. Star fish Retrospective
3. Sail Boat Retrospective
Simple Retrospective
This is the most common way of conducting retrospective, where the retrospective concerns and ideas are
captured on three categories. and the meeting concluded with the identification of action items.
the sample board of this retrospective for co-located and distributed teams looks like as below
SIMPLE RETROSPECTIVE BOARD FOR CO-LOCATED TEAM

SIMPLE RETROSPECTIVE BOARD FOR CO-LOCATED TEAM

SIMPLE RETROSPECTIVE BOARD FOR DISTRIBUTED TEAM

Here the main goal is to capture concerns & ideas that can be categorized on three different areas
1. What went well / Keep Doing
2. What did not go well / Stop Doing
3. Suggestions to improve / Start doing

Creating the Board and capturing Retrospective points

Scrum master facilitate the ceremony, all participants gathered at one room and try to capture the points from
all participants. its always better to capture the points from every one anonymously.
if you are using a physical board, draw one vertical lines and one physical line (a big plus sign), it will create 4
separate areas (refer the above sample board). Then each category a name like , Keep doing, Start Doing, Stop
Doing and Action Item.
Once the board is ready Scrum Master distribute set of sticky notes to all (better if the color of sticky notes are
different for each color for each category. And ask the participants to write the points every one feel on the
Sticky notes, any one can write any number of cards if they need.
This points are only to improve the process and practice not to blame or criticize individuals.
I suggest to distribute those sticky notes during sprint planning itself, to all. So that the team member can
write the notes of retrospective points on respective colors of card at the time of event. its very much possible
to forget small or large events after 2 or 3 weeks. Finally during retrospective they can just show their cards.
If your team is distributed, and meeting physically is not possible, then you can take advantage of many
online retrospective tools like IdeaBordz, Trello etc to conduct your retrospective. Here also I suggest to have
the Retro board created just after sprint Planning meeting, and share the Board link to every one during string
start, so that the team members can get the opportunity to record their points at the occurrence of event or
realization. The team can also add points during the meeting, if every one have accessibility of the tool.
Adding the retrospective point cards and have a discussion

Once everyone ready with the card, Scrum Master or any volunteer can collect the cards and arrange them in
the board, this can be done in more organized way, if the team use color codes, and arrange them accordingly.
For example, if you want to write any points about, “what went well” or “keep doing” use green sticky, for
“what did not go well” or “Stop doing” use a red sticky, for “Suggestions” or “Start doing” use a yellow sticky,
and finally for “Action Item” use blue sticky. This will help the card organizer to easily put the sticky notes to its
appropriate bucket.

This color arrangement is not required for digital or online tool. As the team member will create the cards on
its designated bucket.
Once the cards are arranged on the board, team needs to talk about each cards and needs to be reach to a
mutual understanding, there are chances a conflict which needs to be resolved mutually and may need to
conclude with an action Item.
Cast Your Vote

Now its time to vote the points, each team member can vote or support retrospective cards, the reason for
voting is to get a calculation point to prioritize the cards, the most voted card will be taken with high priority.
The method of voting can be any convenient way the team feels. For a team having the retrospective on a
physical board can add small sticky tags, for example
1. The scrum master can distribute 3 small sticky tags to each member, and once the retrospective cards are
arranged, each member can put their sticky tags to the cards they feel most important to resolve, they can
put all the three tags on one card or can choose three different cards to put 1 tag each. Its not compulsory
 that the member has to put all the three tags, he/she can just use one tag and one card. (remember this is
just an example, you can decide the number of tags and mapping with cards that best suit your need.)
Once the voting is done the physical board may look like this.

or
2. scrum master can have the voting manually and write on each card, which I feel is not that organized.
or
3. In case of Digital tool like Ideaboardz, the tools provide options to vote on each card anonymously, its like a
Facebook “likes” , more likes treated as more voted. Sample is a screen shot of Ideaboardz with option of
voting.

Setup Action Item

So far we learned how we can capture the retrospective points get the voting. Once you have the voting done,
lets prepare the action Item, this is the most important part, we know what is the problem to resolve it we
need to plan some action.
Remember don’t plan too many action item, most team fails on retrospective because of too many action
items. I always suggest any top 3 voted retrospective cards and prepare action items against them.
You can mutually construct best possible action item, and if possible assign some one in the team as owner of
the action item with an ETA.
Your action item(s) can be one retrospective card to one action item, or if there are more than one related
retrospective points, those can be merged to one action Item.
from the above example, please refer the diagram below to understand how the action Items getting
generated from top voted retrospective cards.
Preparing action Item on Physical Board

Preparing action Item on IdeaBoardz

Once you have mutually identified the action items, and planned to execute it you can conclude the
retrospective meeting.
Before we talked about online tools on retrospective, lets learn about two other ways of conducting the
retrospective, Start Fish Retrospective and Sail Boat Retrospective
Star Fish Retrospective.
This is another way to collect retrospective and arrange on board. The concept & goal is same. And This
process also caters three questions
1. What went well
2. What did not go well
 What can be improved
Only difference is, here we make 5 buckets to categorizing the cards. Please refer the image below to
understand how you can prepare the board in your physical white board or how it looks like in Digital boards
like Ideaboardz.
The starfish retrospective distributes the retrospective board into 5 areas.
1. Keep : The practice the team is doing good, and wants to continue the practice
2. More : Some areas of practice the team believe is good, with improvement opportunity, by increasing the
areas where the team believe is beneficial, however it can add more values by doing it more.
Example : “you are doing Grooming Once a week, where you feel its defiantly increasing the backlog
health, and providing groomed stories during sprint planning, however the stories are not sufficient
enough to meet the available capacity, In this case you might want to increase the grooming frequency
from 1 to 2 or 3 times a week ”.
3. Start : The new Ideas or suggestions, that the team believe will be beneficial by introducing as practice.
4. Less : The process or practice areas which are adding values, but the team believe the frequency can be
reduced. And team will get benefit or will not lose any benefit by doing it little less.
Example “you are doing Grooming thrice a week, where you feel the goal can be managed by doing the
grooming twice or once a week, and get additional capacity for construction”
5. Stop : The areas which is not adding values or become obstacles on the process.
The Physical board can be prepared by drawing those 5 lines and give it a star fish shape, or the digital board
can be prepared programmatically (mainly for distributed teams.).
Once the board is prepared the retrospective cards in forms of Sticky notes can be added to respective
sections on your physical board, or it can be added on web on digital retrospective boards. Then do the brain
storming session on each points there may be conflicts between team, Scrum Master needs to take a stand to
resolve any conflicts. It’s not about blaming each other, focus on improving the process and practice.
I suggest to talk about the negative points first and end up with the good points “What went well”, that way
the team will end up with positive feeling and improve moral.
Secondly we can do the same voting mechanism to identify to top rated concerns and prepare the action items
accordingly. The details process of adding cards, voting and preparing action items are explained on the
previous section.
Remember when you are preparing the action items, don’t target for more than 3 action items. Pick top 3
concern and plan the action items accordingly.
For a physical starfish board, you can use some different color of sticky notes and put on the top of most voted
3 retrospective ideas.
Sail Boat Retrospective.
This is another way to execute the retrospective exercise, its also very simple and fun oriented. Here also we
try to find out the areas like
1. What is the goal of the team
2. What are the areas those are stopping or blocking the team to achieve the goal, mainly the practices needs
to improve or can be stopped.
3. What are the area or practices is helping the team to achieve the goal. Mainly the practice area the teem
should keep or can do more.
4. The Risk areas, and practice to start or suggestions to mitigate the risks.
The Retrospective exercise is typically conducted with Co-located team, for distributed team we normally use
either of the two exercise (Simple and star fish) mentioned earlier.
Typically for a collocated team the scrum team gathers at one room having a whiteboard, The Scrum Master
draws a picture as below on the white board.

Sail Boat Diagram

The diagram shows a sail boat floating on water and moving forward a island. It has 4 major component.
1. Island : Goal to achieve
2. Winds: Helping the boat to move forward towards the goal
3. An anchor: causing delay or creating impediments.
Rock: potential risks
When you are drawing the picture on board, you don’t have to a great artist, you can draw it the possible way
you can, with those four components.
Once the drawing is done, The team can capture the input from each member for each area of,

 What went well for the wind area.

 What did not go well for the Anchor area
 Suggestions for the Rocks to mitigate the potential risks
Each member can add as many points they feel on sticky notes, its better to use different color sticky note for
different areas.
Once the sticky notes are ready, the team can put them on the board, refer the below picture.
Now once the sticky notes are pasted on the board, Scrum master or any volunteer can talk about each of the
points and do a brain storming session on those highlighted points.
And then finally the team can do voting on the points, The mechanism of voting will be same as discussed for
Simple Retrospective session. After the voting the board will be looks something like this.
Now once the sticky notes are pasted on the board, Scrum master or any volunteer can talk about each of the
points and do a brain storming session on those highlighted points.
And then finally the team can do voting on the points, The mechanism of voting will be same as discussed for
Simple Retrospective session. After the voting the board will be looks something like this.
So far, we discussed three different types of exercise to conduct the retrospective how to get the retrospective
points and generate the action items, using a voting mechanism.
Group Voting:
There are chances during gathering retrospective points, that same or similar points or ideas coming from
more than one team members. On those situations we combined those same or similar ideas into one group
and give a name to those groups. And vote on those groups, and prepare action item against groups. This way,
the votes don’t get diluted on two similar ideas.
This grouping may not require for online tools you are using, as many online tools like Ideaboardz have the
functionality of voting online on Idea cards. So any one open the board online can see the existing cards, and
then he/she vote ny existing card or create a new idea as card.

Tools you can use to conduct Sprint Retrospective Meeting

There are many retrospective tools available on market few are free and few are for commercially use, I will
explain couple of them here, and also prepare some video tutorials for easy reference.
Now a days even co-located teams have started using internet tools for their retrospective.
Lets talk about some of those tools.
IdeaBoardz
http://www.ideaboardz.com/
IdeaBoardz is most commonly used Retrospective Board, where you can do your retrospective exercise on
Simple Retrospective method or start fish Retrospective method.
On all my previous section of this article, I have used the Ideaboardz as example and screen shot.
This retrospective needs login for the host and participants can contribute to the board just by the link
provided by the host, anonymously.
The tool also provide the options to export the board ideas on excel or PDF format.
GoReflect
https://www.goreflect.com
Go Reflect is another good tool for do retrospective exercise,
This tool provides ready to use template for couple of method like simple retrospective, star fish, Mad-sad-
glad etc. along with it its also provide functionality to create your own custom board.
You can invite team members using their emails, every one can create ideas as retrospective cards. At the
same time The creator can set the board to accept ideas anonymously. You can vote on each card
The tools provide a options to show a dashboard with some analytical report. And functionality to export the
ideas on excel format. It also provide some administrative functionality like notification setting, member
setting etc.
Refer the images below for quick reference
Pointing Poker
https://www.pointingpoker.com/
This tool primarily for Planning poker estimation for a distributed team. However its also provide the
functionality for Capturing Retrospective ideas.
You can start a new retrospective session and invite team members to join the session, or you can join as
observer as well.
it has only one template (Start / Stop / Continue) and no option to vote. This tools provide a check box to add
ideas anonymously.
I personally didn’t found it very useful or have enough functionality. You may found it useful.
Scatter Spoke
https://www.scatterspoke.com

This tool provide the platform of doing your retrospective, by default it shows three columns
1. What went well
2. What did not go well
3. What needs changes
the columns labels are editable, with option to add 1 more column with custom text, that you can use for
Action Items.
This tools provide option for voting on idea cards. Story cards color are different on each column.
The creator of the board can invite team members by using a link. and member can access the board
anonymously, to add their ideas and vote. This tool provide a option to pin the idea card, you can use the pin
to shortlist ideas. This tool also provide functionality to prepare grouping of multiple ideas into groups
You can export the ideas on PDF or CSV format, or you can email it as well.
Scrum Toolkit
https://www.scrum-toolkit.com/

This is a wizard based tool. it mention the retrospective exercise as game. it has two template
1. What went Well & What can be Improved
2. Start Doing, Continue Doing and Stop Doing
The Wizard have 6 steps
1. Create the Game
2. Join the Game
3. Adding Points
4. Grouping
5. Voting
6. Results.
This tool provide an url to share with team member to participate. Participants can join directly to the board
without registering. The tool will not show the ideas of other team member until the other members confirms.
The state of the wizard can only be changed by the creator of the board.
The Voting mechanism is to by decide the item is more important or less important, and independent to each
column.
On result column, it shows the most voted item on top. and you can prepare the action item based on the top
voting. creation of action item is not possible in this tool.
The Report Provides a textual report after all the stages of the wizard.
There are many others retrospective tools over the internet, you may already have or will discover them. You
can refer the above tools if you have not discovered and liked others yet.
I will make some quick video on those tool how to conduct retrospective using those tools.

Outcomes of Sprint Retrospective Meeting

Now once we are done with our Retrospective exercise, one of the prominent outcome we achieved is the
Action Items: 1 to 3 action items has now emerged, that the team will work on to improve the process, or to
mitigate risks. This will help add values to business faster.
Inspect & Adapt: The team inspect the practice & process and adapt the changes for betterment to reach the
goal, ultimately benefit the business and company.
Improve Team Collaboration: The teams collaboration improves, which help them to become self organizing
team. Team members feels value of their voice to overcome the bottlenecks. They become more motivated
and encouraged, Improves productivity.
Reduces Gaps between development team and Customer : The Development team closes the distance and
gap with Product Owner from customer side, and resolved issues or challenges related to requirement,
Product Backlog, Acceptance. The team gets more aligned with the absolute goal they are working on.
Fun activities improve team bonding and motivation: Many team conduct the exercise as fun games, keep the
team motivated, engaged, and its become a refresher. as the team is going to start a new Sprint from next day.

After Sprint Retrospective Meeting activity

Once you have concluded the retrospective. the scrum master can circulate the Retrospective notes with
action items, most of the digital tools provide report to export, that can be easily shared. I suggest, Scrum
Master to keep a record of all retrospective report sprint by sprint for future reference. And also prepare a
status tracker of the action items, with progress status, initiated date, primary owner etc.
Working on Action Items: The most common reason of failing to get the benefit of retrospective meeting is,
not working on the action item seriously, and the meeting become a formality. So Its very very important to
work on the retrospective action items. talk with with whole team at-least twice a week, for example every
Tuesday and Thursday. I found teams sometime complains we already have too many meeting, lets not add
more meeting, on those situations you can talk about the action item for 5 minutes after your DSM is over as
16th minute discussion item. Its up to you and your team what best suitable for you, but the action item as to
be discussed with the intention to close it.
Important Notes
There are few important points you need to keep in mind to have your retrospective successful and a
successful agile team.
Many company’s management thinks retrospective is not required or waste of time, that is just not correct, If
you are running your project on Scrum Framework, Inspect and Adapt is very important.
Secondly at many team the retrospective is become a blame game, and deviate from the primary goal of the
ceremony. It has to be on a positive mindset to improve. Speak gently give respect to all, highlight the
opportunities of improvement and proceed.
Because of weak facilitation, team member may lose interest on the meeting, Scrum Master needs to engage
the team and all participants in a way, based on the culture and nature of the business/project. So that every
one can see the value and benefit of the meeting and also value of their participation.
This is not just a meeting to improve your process, it’s the opportunity to improve any practice to reach the
goal, many time Scrum Master become to process oriented that goes against the culture of a team
transforming from traditional to agile. Participants on those situation feels annoying or get bored from the
meeting. On those case Scrum Master Please be very careful, you need to facilitate to keep everyone’s interest
intact with a positive result.
If you don’t address the above issues, you will get low attendance or some time no attendance on
retrospective, and the team will become lose the chance to inspect and adapt the improvement opportunity.
And end up with not getting value addition of doing agile.