Scrum In A Nutshell

The purpose of writing this blog is to provide the synopsis of the whole.


Scrum is an incremental delivery approach that makes it possible to get the highest priority task out of the door first and fast. It eliminates the features that are not important or are redundant and hence saving cost and resources.


  • Product Owner: Responsible for the product and business needs. Is the voice of the customer.
  • Scrum Master: Servant-leader responsible for facilitating the process and for removing the impediments that hinder the team from focusing on development.
  • Development Team: Cross-functional, self-organized team responsible for delivering shippable product increment.
  • Stakeholders: Any person or team who has a vested interest in the product.


  • meeting

    Stakeholder Meeting: A meeting held to discuss and formulate the business case between the stakeholders, customers and product owner. The result is the product backlog.

  • Sprint Planning Meeting: A meeting of team to determine what will be done in the next sprint. Outcome is the Sprint backlog.
  • Daily Scrum and Scrum Execution: A 15 min daily stand up meeting to inform the team of the status, progress and roadblocks.
  • Sprint Review: A meeting to demonstrate the sprint results and get immediate feedback from the product owner and the stakeholders.
  • Sprint Retrospective: A meeting to reflect on the past and to improve the future.
  • Backlog Refinement Meeting: Also called backlog grooming for breaking down epics into user stories and maintaining the prioritization of the product backlog.


  • paper-2199502_1920Product Backlog: Prioritized list of items with item of highest value to customer on top.
  • Product Backlog Item: Item on product backlog specifying what needs to be done on a particular requirement. Usually in form of user stories.
  • Sprint Backlog: List of highest priority items from product backlog selected by team to work upon in the next sprint.
  • Product Increment: Working product increment at the end of the sprint that meets team’s definition of “done”.


  • resources3Estimation: Relative size estimate for tasks in form of ideal hours or story points.
  • User stories: Short description of the user requirements containing minimum information needed for developers to estimate it.
  • Cross-functional: People from all competencies and domain knowledge work together as a team.
  • Self-organizing: Self-manage without externally assigned roles.
  • Sprint: It is a short span of time in which product backlog item is converted into shippable product increment.
  • Definition of “done”: Definition of done is the list of criteria which when fulfilled a user story can be marked as done.
  • Scrum of Scrums: It is a technique used to extend the scope of scrum to large groups. In this large groups are divided into small teams and then the designated person meets with other team designated people to collaborate in scrum of scrums meeting.

Information Radiators:

  • graphVelocity: Measure of the amount of work a team can produce at the end of the Sprint.
  • Sprint Burn-down Chart: Displays total task hours remaining for the team within one sprint.
  • Product Burn-down Chart: Tracks progress of the project. Depicts number of sprints on X-axis and story points (work remaining) on Y-axis.

Estimations in scrum

Estimation plays an important role in management. At every stage of project business-tasks-2932687_1920management an estimate is required. It may be of the duration of the project or the cost of one. Estimation helps in answering some very important questions like: “How much work will be done at the end of sprint?”, “What will be the tentative release date of the project?” or “How many features will be completed in the sprint?”.

For estimation it is important that we first estimate the size of the product being built and then measure the rate at which the work can be done.

When to start: Once the project has been approved and product owner has sketched out enough details to form a product backlog, then the team can be involved to add numeric estimates to the items present in the product backlog. Break them into smaller parts if need be to make precise estimates. The target should be to estimate as precisely as possible.

Estimations can be made in form of either ideal days or in story points. It is common for the working teams to start estimating in ideal days for a few sprints and then move to story points when they get accustomed to the idea of estimation.

Ideal Days: This represents the number of days needed to complete a story. It means person days needed to complete the task. Three assumptions needed to be kept in mind when estimating a story in ideal days are:

  • That story will be the only thing you will be working on
  • You will have everything needed to complete the story e.g. all resources like database, software license etc.
  • You will not be disturbed in between your work by phone or in person.

As per these assumptions you basically will be working in a cocoon. In real world 100% dedication is not possible hence ideal days is the estimation of the relative size of the story and not the time. It would be wrong to map the estimations to the calendar days.

Story points: These measure the magnitude of a PBI. Magnitude can depend on multiple factors, like size of the problem or its complexity. A problem may be large but not complex on the other hand it can be small but the effort needed to develop it might not be. Story point is the relative measure of the enormity keeping into account the complexity and the physical size.

Duration of the project: Duration of the project can be calculated by adding the estimated sizes of PBIs in the product backlog and dividing by the average velocity of the team.

Sum of sizes of PBIs / Average velocity = Duration of project

Planning Poker: It is a technique described by James Grenning and popularized by Mike Cohn. Important concepts to bear in mind when using poker planning :

  1. Decision should be unanimous
  2. Keep into account the experience of others
  3. Enable discussions to remove misunderstanding and infuse clarity
  4. Estimated sizes should be relative to each other
  5. Group same size stories for effective estimation
  6. Use empirical data for estimating

Poker cards_scrunageSteps for playing poker:

  1. Decide on a sequence of numbers. The most popular sequence is the one proposed by Mike Cohn i.e. the Fibonacci series: 1,2,3,5,8,13,20,40 and 100.
  2. The product owner presents and clarifies the product backlog item (PBI).
  3. The team discusses the item and asks questions to clarify the doubts.
  4. Each team member chooses a card privately.
  5. All members are asked to simultaneously expose their privately chosen cards.
  6. If everyone has same card then the consensus is reached. Else team members confabulate their assumptions and misunderstandings. The largest and the smallest estimates must review.
  7. After discussion repeat step 4.


Team velocity


Velocity is the sum of estimates of completed features per iteration.

It is easy to measure. At the end of each sprint, we add the size of estimates of every item that was completed during the sprint. If the item was not finished, then it does not count towards velocity as an unfinished task has no value to the product owner.

velocity chart 1Velocity is best expressed as a range. e.g. “Team typically completes 20-25 stories per sprint”. By doing so, uncertainty can be communicated. In any case, estimates are not commitments and it is important that we do not treat them as one. Velocity should not be used as a performance metric for the team’s productivity. It is a planning tool and should be used as such. So, instead of using average velocity it is best to use the lowest and the highest velocity and hence the range between the low and high velocity.

Forecasting: Velocity is based on the empirical data. It is important for any new team to run a couple of sprints before more accurate predictions can be made. When the team has run a few iterations and have derived an actual velocity measure, then the forecast can be discarded and the actual numbers to predict the release date can be used.

After a few iterations, velocity typically stabilizes and provides enough base for improving the accuracy of near-term and long-term project deliverables. It may fluctuate from sprint to sprint but over time the team’s velocity should improve.

Velocity Chart _Scrunage

Velocity Chart

Velocity Chart: It is the graph that shows the sum of estimates of the completed work delivered across all iterations. Velocity should be tracked throughout the Sprint and should be made visible to all team members. A sprint burndown chart can be used for this purpose.

Agile Manifesto – Principles

Agile mindset is guided by 4 values and 12 principles. Agile manifesto is the basis of agile framework and applies to all people and teams following agile.

12 principles behind agile manifesto:

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  2. manifesto_principlesWelcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  4. Business people and developers must work together daily throughout the project.
  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  7. Working software is the primary measure of progress.
  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity–the art of maximizing the amount of work not done–is essential.
  11. The best architectures, requirements, and designs emerge from self-organizing teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Agile Manifesto – Values

Agile mindset is guided by 4 values and 12 principles. Agile manifesto is the basis of agile framework and applies to all people and teams following agile.

4 values as mentioned in agile manifesto:

  1. manifesto_valuesIndividuals and interactions over processes and tools: Agile manifesto highly regards face to face conversations to convoluted processes. Agile manifesto was formulated when teams were small and co-located. In today’s dynamic environment with work from anywhere policies this can be achieved by virtual co-location. This enables communication and removes misunderstandings. Processes and tools should be used to help the individuals perform their tasks efficiently. If processes and tools are regarded over people then individuals are less responsive to change and less likely to meet business needs.
  2. Working software over comprehensive documentation: Detailed documentation for product development like technical details, lengthy requirement specification documents use up the developer’s time and hence hinders the timely delivery of the product and jeopardizes the deadlines. Agile does not eliminate the documentation. It curtails it to minimum needed. The developer does not need to write the details in their entirety, he can however jot down the main points needed for development.
  3. Customer collaboration over contract negotiation: Negotiations in traditional development are done in the beginning once the project has been excepted. For drawing up such type of a document it is important to outline all the details beforehand and hence leaves less or no space for change. Agile encourages the involvement of the customer at all phases of development. This ensures that the end product is aligned with customer requirements and business needs.
  4. Responding to change over following a plan: In agile the product is released in small increments and hence embraces change and shift in priorities along the way. If details are formulated in the beginning before starting the project then any changes than come mid way would consume time and money.



Epic vs Theme vs Story vs Task

This is most commonly asked question as to what is the difference between an epic, theme, story and a task. Underneath I have tried to explain these terms in simple language.

Epic: An epic captures a large amount of work. It is essentially a large user story than can be broken down into multiple smaller user stories.

Theme: Themes are group of related stories. Stories in a theme are dependent on one another. They however do not need to encase specific work or be delivered together. It is like a tag to group together similar stories.

Story: A story is an agreed upon unit of work by the developers and the stakeholders. It is the primary development artifact of scrum.

Task : A task is a smaller part of the whole story. The story is worked upon by the whole team whereas a task is worked upon by each individual in the team.

Scrum Terminology

Scrum Checklist

“Success is not created by one person but by a team that comes together as one” – Jillian Farrar


Scrum Team consists of three core roles:

  • Product Owner: Product Owner is the person who understands the business need and has product vision. He is responsible for guiding the development team in developing a product that is in compliance with the business.
  • Scrum Master: Scrum Master is the person who acts as a facilitator and coach to make sure that the team adheres to the scrum principles and functions as a buffer between the external interference and the development team to ensure the smooth working of the development team.
  • Development Team: Development Team is a group of self-organized members who are committed to a sprint and deliver potentially releasable increment of product within an agreed upon time frame.

From my experience as a scrum practitioner, I have consolidated a checklist for each role.

Product Owner Checklist:

  • Define release and sprint goals.
  • Update product backlog daily.
  • Prioritize product backlog daily.
  • Meet with team to clarify requirements.
  • Clearly explain the product vision to the team.
  • Meet with stakeholders when needed to coordinate and capture requirements.
  • Communicate release plans with stakeholders.
  • Make product log visible to all team members.
  • Maintain an understanding and trusting relationship with scrum master.
  • Organize workshops for continuous development.
  • Arrange meetings with customers, stakeholders and team.
  • Arrange sprint planning meeting with team.
  • Participate in sprint review meeting and provide feedback.

Scrum Master Checklist:

  • Conduct daily scrum.
  • Update list of impediments from daily scrum, email and other communications.
  • Follow up on impediments reported by team.
  • Order any equipment needed by team.
  • Mediate through conflicts.
  • Write sprint report to stakeholders once a sprint.
  • Chase up on any information holding up sprint backlog.
  • Make sure burndown and task boards are visible in team room.
  • Arrange meetings and have chats to coach new members, product owners, stakeholders on agile and scrum values.
  • Help team create good information radiators.
  • Help product owner write user stories, order product backlog items.
  • Help team focus by acting as a buffer between external distractions and team.
  • Help team maintain scrum tools (charts, backlogs, story boards etc.).
  • Timebox all meetings.
  • Continue learning about Agile and Scrum via different platforms like user groups, attending conferences, reading books and writing blogs.
  • Communicate with other scrum masters in the organization.

Development Team Checklist:

  • Update task board with time remaining on task.
  • Report any impediments to the scrum master.
  • Clarify requirements with the product owner before starting and finishing any story.
  • Achieve daily targets.
  • Attend daily scrum and be punctual.
  • Communicate with team regularly.
  • Keep solutions simple.
  • Focus on creating a shippable product using pair programming, test driven development, code reviews and continuous refactoring.