Sprint Planning

Discover time-boxed meeting, estimate the capacity, Sprint Backlog, Sprint Goal, Sprint PBI and detailed plan

Sprint Planning overview:

  • The first thing to do in each Sprint is the Sprint Planning, which is a time-boxed meeting attended by all 3 scrum roles and usually fixed to 8 hours for a one month Sprint or shorter for Sprints of less than a month.
  • The Development Team should estimate the capacity of work it can deliver in a single Sprint from the already ranked and ordered Product Backlog with the highest value items on top.
  • As soon as the Product Backlog is mature enough, with necessary number of stories the Development Team can start the first Sprint without waiting until the Product Backlog is 100% planned with all requirements gathered and cleared.
  • The Sprint Backlog will be ready at the end of this meeting and the Development Team should be able to describe what items they will deliver through the Sprint, and how they will do it.

Product Backlog to Sprint Backlog

  • The Development Team selects an appropriate number of items from the top of the Product Backlog, and puts them in the Sprint Backlog, to deliver in the current Sprint.
  • The Product Owner also ensures that the items (stories) are easy to understand.
  • The amount of work for each item is estimated by the Development Team and the total amount of work of the selected Product Backlog items is close to the estimated capacity of the Development Team.

Sprint Goal:

  • Following the selection of the items to the Sprint Backlog, the Scrum Team should draft a Sprint Goal, an objective that should be met within the Sprint through the implementation of the Product Backlog.
  • The Scrum Goal provides guidance to the Development Team on why it is building the Increment.
  • This is a sample Sprint Goal: We are going to enable all the essential parts of the website store to set up a complete purchase process. This makes other features of the website more meaningful to the customer.
  • The Product Backlog should be ordered in a way that facilitates setting Sprint Goals.
  • The scope of the Sprint, which is made up of the items selected from the Product Backlog, might need to have more details through the Sprint, which should be aligned with the Sprint Goal, and likely re-negotiations for them should be done in presence of the Product Owner.

Detailed plan:

  • When the items to deliver are selected and the Sprint Goal is agreed, it is time to plan how they will deliver the items into a Done product Increment and realize the Sprint Goal.
  • Having a detailed plan for the first few days is enough and the Development Team can prepare detailed plans for the rest of the work later on.
  • A detail plan, as shown in the next figure, is a breakdown of a Product Backlog item into detailed tasks needed to be done in order to create the item.
  • Each task might have estimates, dependencies, and similar information to make tracking possible.
  • These tasks are defined by the Development, explaining how they will deliver each item, and are created at the Sprint Planning meeting or throughout the Sprint.

The Sprint Backlog consists of the following:

  • The Sprint Goal
  • Selected items from the Product Backlog, to be delivered through the Sprint
  • A detailed plan (tasks) for turning the selected items (stories) into Done Increment of the product and to realize the Sprint Goal

Sprint board:

  • The three Sprint Backlog elements (Sprint Goal, Product Backlog items selected for the Sprint, and the detailed plan) should be shown on the board.
  • The board should also have an  easy way for tracking the tasks and items in To Do, Doing and Done columns.
  • Extra tasks have been added to the lower ranked items (items #3 to #5), which is the ongoing detail planning done through the Sprint.
  • Items in the Sprint Backlog usually have the same order they had in the Product Backlog, therefore, the Development Team should work on the higher ordered items first.

Get the book

Daily Scrum

Discover 15 minute daily, same place/same time, sprint progress (board, burnt down chart), scrum team only, 3 questions (done, to do, obstacles)

Daily Scrum overview

  • The Daily Scrum is normally a 15 minute meeting for the Development Team to inspect the work since the last meeting, and synchronize their work and plan for the next 24 hours.
  • It must be held on a daily basis, ideally at the same time and place.
  • The Daily Scrum meeting should be held at the same time and same place throughout the Sprint, to minimize the complexity.
  • It is just for the Development Team and it is not a status meeting for all the stakeholders.
  • They should assess progress towards the Sprint Goal and forecast the likelihood of completing the items before the Sprint is over.

During the Daily Scrum, each member of the Development Team should answer these three questions:

  • What has been accomplished since the last meeting
  • What will be done before the next meeting
  • What obstacles are in the way

Sprint progress:

  • The Development Team should also monitor Sprint progress each day and therefore it is a good idea for the Sprint board (wall chart) to be visible during the Daily Scrum meeting.
  • They can use a burn-down chart to track their remaining work and check to see if they are going to complete all items before the end of the Sprint.

Get the book

Sprint Review

Discover 4 hours, inspect the Done items, demo, meet DOD, update PB, get feedback/changes, status

Sprint Review overview:

  • At the end of the Sprint, the Scrum Team and other stakeholders gather and hold a four hour meeting to present and inspect the Done items (the Increment) from the current Sprint.
  • The Development Team demonstrates and explains each one of the items.
  • The Development Team does not present an item, unless it is 100% complete based on the agreed definition of Done, which should be reviewed by the Product Owner before the Scrum Review.
  • The duration of this meeting is normally four hours for a one month Sprint. If the Sprints are shorter then this meeting will be proportionally shorter.

Sprint Review objectives:

  • Update the Product Backlog by marking off Done items as complete and add new items or change the existing ones if necessary.
  • The presentation of the Increment in this meeting is intended to collect feedback and raise change requests at the earliest time possible.
  • We welcome changes in Scrum and encourage them to be demanded, because it increases the satisfaction of the customer and will create a final product that better matches the needs of the customer.
  • The Product Owner discusses the status of the Product Backlog and the likely completion dates based on the progress. 
  • Finally, the whole Scrum Team collaborates on revising the Product Backlog based on the output of the Sprint and the feedback received from the customer.

Get the book

Sprint Retrospective

Discover three hours, lesson learn, process improvement, inspect (people, relationships, processes, and tools)

Sprint Retrospective overview:

  • This meeting is normally three hours for a one month Sprint or shorter for proportionally shorter sprint.
  • After the Sprint Review and just before the end of the Sprint, another meeting will be held, aimed at process improvement (learning lessons), which is called Sprint Retrospective.
  • We will review (inspect) the Sprint, with regards to people, relationships, processes, and tools, and identify ways of improving them in the next Sprint.

Sprint Retrospective objectives:

  • There is a rule: we should always look for ways to improve. It does not matter how little the improvement is, there should be an improvement.
  • This meeting is a formal opportunity for improvement, even though we do not limit our improvement to the results of this meeting. 

Get the book

Product Backlog Grooming

Discover reviewing and revising PBI, ordering, prioritizing, ongoing activity, max 10% of dev team

Product Backlog Grooming overview:

  • Besides the time boxed event discussed before, there is also an ongoing activity in Scrum projects called Product Backlog grooming. It is the act of reviewing and revising Product Backlog items, which typically involves adding detail, estimates, and order to them.
  • The Product Owner is responsible for ordering (prioritizing) the items and the Development Team is responsible for estimating those items.
  • The main difference between this activity and the five Scrum events is that Scrum events are all time-boxed, but grooming is an ongoing activity that happens throughout the Sprint.
  • This activity should not consume more than 10% of the time of the Development Team.

Get the book


Discover product-oriente, being productive, limit the work time to a reasonable amount, 1-2 days recharge batteries

  • It does not matter how much we work; what we produce is important.
  • We should be product-oriented, rather than activity-oriented.
  • One way of being productive, is to limit the work time to a reasonable amount, and have frequent off times.
  • That is why it is recommended (but not necessary) to have a slack between each two Sprints.
  • Let’s have a day or two off to recharge your batteries, read some relevant articles, and check out what other teams are doing.
  • Slacks can also be used for reading articles, taking part in courses or workshops, spending time on creative projects, etc. 
  • We will be back after the slack, and repeat the same cycle over and over again, each time with a little improvement, until the final product of the project is delivered, and the client is completely satisfied with it.

Get the book

Scrum Artifacts

Discover Product Backlog, User Stories, DOR, Sprint Backlog, Increment, DOD, Product progress, Sprint progress

Scrum artifacts of management activities are created to increase transparency of information related to ]project delivery and provide opportunities for inspection and adaptation.
There are six artifacts in Scrum:

  • Product Backlog: an ordered list of everything , aka all of the stories, that might be needed in the final product
  • Sprint Backlog: selected items (stories) from the Product Backlog to be delivered through a Sprint, along with the Sprint Goal and plans for delivering the items, aka the tasks needed to complete the Sprint Goal
  • Increment: set of all the Product Backlog items completed so far in the project, up to the end of a certain Sprint
  • Definition of Done: shared understanding of what it means for a story to be considered complete
  • Monitoring Project  Progress: performance measurement and forecast for the whole project
  • Monitoring Sprint Progress: performance measurement and forecasts for a single Sprint

Get the book

Product Backlog

Discover ordered list, simple, improving, start when sufficient stories defined , importance value, higher items at the top, work estimate

Product Backlog: ordered list of stories.
Product Backlog description:

  • The Product Backlog is an ordered list of everything that might be needed in the final product of the project (a wishlist of the expected final product).
  • All items are described in simple business language (non-technical) and all of them are presentable to every stakeholder.
  • Every requirement and every change in the project will be reflected in the Product Backlog.
  • The Product Backlog is dynamically changing and improving; it is never complete.
  • The first Sprint can be started as soon as the Product Backlog has a sufficient number of stories defined and we do not wait until the Product Backlog is complete to start delivering the items
  • The Product Owner sets a number of factors (ROI) to determine the value of each item for the business, summarized into one importance value shown with each item.
  • The Product Backlog items are ordered based on their value, with the higher items at the top so it will be sooner delivered by the Development Team.
  • Top backlog items should be clear and detailed.
  • Each Product Backlog item should have a work estimate completed by the Development Team, to determine the team’s capacity for a given Sprint (number of items that could be completed).

Information available for a single Product Backlog item in a typical Scrum tool like JIRA include:

  • Story Name: the user story itself  e.g. "As a user I want to login to my account to get access to my data"
  • Story Description: all the relevant information about the story so that the whole Scrum Team can have access to it.
  • Story Complexity: defines the nature of the story and used for Sprint Planning (usually the more complex a story is, the more uncertain its estimate would be)
  • Story Estimate: estimated volume of the story determined by the Development Team.
  • Assignments: story can be assigned to any person in the team (even if whole Scrum Team would remain accountable for it)
  • Tasks: breakdown the story into tasks (detailed planning) and track them separately.
  • Comments: each member of the Scrum Team can leave comments and collaborate with others

Optional fields:

  • Categories: easy way to ease of access and maintenance when multiple stories in the backlog (act as a normal WBS)
  • Colours: You can set different colours to each story to differentiate them visually in the Scrum board. This is another way of grouping/categorizing items.
  • Tracker:  You can record time spend on each story for further analysis, refining estimates, billing, etc.
  • Attachments: attach relevant documents and use the software as a document management tool.
  • Alerts: optional custom alerts can be set here
  • Due Date: optional custom due dates to track stories
  • custom fields

NOTE: Collaboration features are more important when the Scrum Team is not co-located and traditional ways of collaboration are not possible.
Product Backlog process guidelines:

  • The Scrum Team should add details, estimates, and order to the Product Backlog items all the way through the project, which is called Product Backlog grooming and it should not consume more than 10% of the time of the Development Team.
  • The Product Backlog is created more based on discussion rather than documentation.
  • The Product Backlog items (aka stories) should be easy to understand for non-technical stakeholders.
  • It is common to break the large stories into two or more stories later.
  • There should be only one Product Backlog, no matter how many Scrum Teams are working on the project, as the Backlog is a representation of the scope of the final product.

Get the book

Sprint Backlog

Discover created during Sprint Planning , consists of Backlog stories, goal, plan

  • The Sprint Backlog is created during the Sprint Planning event which is the first event in a sprint.
  • The Sprint Backlog is frozen (means that items cannot be added or removed during the Sprint) after the Sprint Planning and the Development Team will focus on delivering an Increment of Done based on this plan.
  • It might be necessary to get more information, justify, or clear some of the items during the Sprint, which should be done in the presence of the Product Owner.
  • The detailed plan which is normally not complete at the end of the Sprint Planning will become more complete as the Sprint continues.

The Sprint Planning event consists of the following:

  • Backlog stories: a number of items selected from the top of the Product Backlog, based on their estimated work and the estimated capacity of the Development Team
  • Sprint Goal: help describe the real meaning of the items and direct the efforts of the Development Team
  • Detailed plan: for delivery of the items and realization of the Sprint Goal during the Sprint

Get the book