Daily Scrum, Scrum Review and Retrospective

Scrum Sprints are repeated time-boxed intervals with Scrum Events within. We already talked about the Sprint itself as well as Sprint planning. This event takes place at the beginning of each interation. During the Sprint, the team works on implementing the features selected in the Planning Event.

Daily Scrum

Duration is limited to 15 minutes and held daily at roughly the same time and place. The Development Team attends, the Product Owner or other people may silently join. Goal oif this event is to synchronize the team members.

Each member of the team has to provide answers for these questions:

  • What did I do since the last meeting?
  • What will I do until the next meeting?
  • Is there anything that blocks me from doing  my stuff?

Please note that the meeting is an informal one. No adoptions to the backlog were discusses here, nor are any problems. This takes place after the Daily Scrum.

It’s is a good idea to have an agenda beforehand to optimize the meeting.

For scaled Scrum there is a Scrum of Scrums meeting after the Daily Scrum where each team sends a representative to synchronize over team barriers and to talk about dependencies between teams.

Sprint Review

At the end of an iteration there is the Sprint Review. It has a duration of two hours for a two weeks long Sprint and four hours for a month accordingly. At the review meeting the Scrum Team (Development Team, Product Owner and Scrum Master) meet with the customer and external stakeholders to present what has been done during the Sprint. It is an informal meeting. Only items defined as “done” are presented. The Product Owner reviews the items beforehand and the team demonstrates the new features of the increment.

The main purpose of this meeting is to collect feedback and possible change requests from the customer. This early feedback is the base of the adaptive techniques lived by Scrum.

Once the feedback is gathered, the team revises the Product Backlog based on that feedback.

Sprint Retrospective

Duration: 90 minutes for two weeks sprints and 3 hours for a month. This meetings takes place after the Review and before the end of the sprint.

This meeting is aimed at improving the processes and relationships, reevaluate the tools and in general everything to improve the quality of the product and the people who work on it.


Sprint Planning

We talked about Sprints in general in the last post. Let’s get into some more detail now concerning the Events within a Sprint. It’s the container for these Events:

  • Sprint Planning
  • Daily Scrum
  • Sprint Review
  • Sprint Retrospective

We will talk now about the first event, the Sprint Planning Event. The other events are described in more detail later on. Sprint events are formal opportunities to inspect and adapt. They also enable transparency in the process.

Sprint Planning

Sprint Planning is time-boxed, 4 hours for a two week sprint and not longer than 8 hours for a month. All three roles attend this meeting.

Prerequisites: the Product Owner has already some entries (user stories) in his Product Backlog ready for development (this basically means, that the entries  are ranked by value). The team takes some of the entries from top of the list (those with the highest value) – those items are meant to be “done” a 100% by the end of this Sprint. If some details aren’t clear to the team, it’s the Product Owner duty to explain those.

These items are put onto the Sprint Backlog which contains items that are planed to be delivered at the end of the sprint. Each item is now estimated by the Development Team. The sum of the estimated items should be close to the capacity of the team.

A Sprint Goal is defined. This goal should be met by implementing the Product Backlog items chosen for this Sprint. It’s, in other words, a description for the planed increment.


In the next step, the chosen user stories are transferred into more technical tasks. It’s okay to only create as many tasks as needed for the team to get started and review the user stories later into the sprint. This is close to what many may known as traditional ticket systems. Tasks can have a time estimation, dependencies to other tasks (tickets) and an assignee.

So the Sprint Backlog basically has a hierarchy with the Sprint Goal at the top, a list of user stories from the Product Backlog which are needed to reach that goal and a set of tasks for each user story (or Product Backlog item) which are required to deliver the functionality described in the item. While the Product Backlog items are picked at the beginning of the planning event, the tasks are organized by the team and change as the Sprint evolves.

It’s common practise to add a state to backlog items and tasks such as “to do”, “doing” and “done”. Items with a higher value should be worked on first.

In scaled Scrum (Scrum with more than one team), each team has its own Sprint Backlog and its own Planning Event.

Overview: Sprints

Now let’s talk about the sprint basics. We will come back later to this topic in a bit more detail, but for now, an overview is all we need. We will talk about Scrum Events and sprints. You may already know that the project itself is separated into a set of discrete time-boxed things called “sprints”. The maximum length of a sprint is one month. The sprint itself is a so-called “Scrum Event” but it also contains other events within. An event is something that happens while working the Scrum way.


The goal of a sprint is to deliver an increment, a working piece of your product you could publish to the customer if needed. increments are one or more of the items from the product backlog, converted into a usable thing. increments are a set of features you may release to the public (you actually don’t have to release it for real. Point is: you should be able to). You pick some items you want to work on during the sprint at the beginning of each sprint, but you don’t change them once the sprint has started.

Another thing is: you don’t start several items at the same point. You focus on the one with the highest value (which is the first on in the sprint backlog as the Product Owner has already sorted things for the team at this point) and add other features slowly once things are going.

Sprint duration

Time-boxing is an integral part of the Scrum approach. It’s the Scrum way to deal with changes and which helps us to focus on a certain topic. It has a maximum but fixed length, during that period the target we want to archive is known and fixed. The duration is something so important that you are not allowed to change it as you want. You committed to an interval and you stick with it for some time. This does not mean that it is not changeable per se – if you find yourself in the need to change it, do it. But consider it to be a thing you have to spend some thought beforehand. Don’t change it frequently.

A sprint may even be cancelled by the Product Owner. This may happen when the goal of that sprint became obsolete or strategies changed, the marked moved or other sorts of bigger changes from without makes it senseless to continue the sprint.

The definition of ‘Done’

People should find an agreement on what it means if something is “done” very early on. While something is not “done”, it won’t be presented to the customer and it won’t be part of an increment. The Development Team and the Product Owner must agree on what “done” means.

If there are more items in the Sprint Backlog than the team can manage to finish, it’s not a big problem. The items not done are returned to the pool of items for the next sprint (the Product Backlog) and finished at a later time, in another sprint. Keep in mind that this is not a bad thing. Be honest with the team members and expect them to be honest with you. If you push them, they’ll add buffers to the time estimates the next time. This will generate huge problems over time.

Velocity and Burn down

Backlog items have a value. If you sum up the value of items that were delivered by the team at the end of a sprint (the items “done”), you end up with some sort of number – be it hours the team worked on something or ‘arbitrary’ story points. That number is your sprint velocity, the speed at which you are moving towards the final product.

If you compare the work done and the passed time within a sprint, you get the burn-down chart, which tells you if you are ahead or behind schedule for the actual timeframe.

Product Backlog Refinement (Backlog Grooming)

Backlog Grooming describes the act of constantly reviewing and revising the items in your Backlog and adding details to the items. While most things in Scrum are time-boxed (they have a fixed length), the grooming is an ongoing activity. It should not cost more than 10% of the Development Teams’ time. The Product Owner however may invest more.

When the Product Owner adds items to the Backlog, (s)he explains it to the team. The team then may provide a time estimate to realize that feature. In this way, the backlog is ready to use later when it is time for Sprint Planning.

Roles in Scrum

In Scrum it’s about teams and the roles of the team members. Remember: we have to work together to build a good product and we aren’t expected to work against each other, neither a coworker nor the customer, to deliver the best possible outcome in this game of software delivery.

The Team

First thing is the Scrum team itself. It is an internal team. Most likely every team member is assigned exactly one role (see below) and while it is possible to assign more then one role to a single person, I’d strongly advice against to keep the focus on point.

The team is cross-functional, it can work on its own and does not have dependencies to outside of the team. Also, the team is self-organized, saying that it is not managed from outside. It is responsible on its own for its success and the success of the whole project.

Teams are meant to work in a flexible, creative and productive way. Later we will see how we try to archive that in more detail.

The Customer

Noticed the word “internal” above? We talk about people from your company, people you work with. Of course there are other people with a given interest in the project. Those are external stakeholders and we won’t talk much about them as they do not play a big part in the way Scrum works – although it is easier if they understand how Scrum works and maybe even adopt parts of the methodology. And please also note that the customer in this context may even be another part of your own company, not only an strictly external stakeholder.

The roles within the team

Important fact here: the team consists of exactly and always and only three roles which are the product owner, the scrum master and the development team. We will talk about each one now in more detail. Please remember that it is possible that a single team member has more than one role, so that the product owner or the scrum master may be part of the development team for example. Also remember that this is not encouraged to not lose focus.

The Development Team

The tasks which the team is to deliver are organized within the product backlog. Slowly transforming those items into working software, that’s what the development team does. Furthermore the team is responsible itself for correct delivery as it acts autonomously (self-organized, see above). The team acts, succeeds and fails as a whole. The development team does not receive orders from someone outside. The team members know what to do and are able to do so in an adequate way. The price for this freedom is the responsibility to deliver working software.

There are no specialized roles within the team. No testers or front end developers. All members have the same role of a development team member as titles would weaken the team spirit. Each member is responsible to the same amount for the output created.

The team size is in between 3-9 people who work full-time on the project. In a project, there can be more than one team (“scaled scrum”). The teams work in sync and are connected to the time box the sprint sets. Technical knowledge is in the teams.

The team estimates the items when they select them for a sprint (details on this can be found later). They also measure the Sprint performance (and also here: see later).

The Product Owner

This is the management guy from your company. For a product there can be only one owner, even when having several development teams ready. The product owner takes care of the backlog items, or in other words: the tasks to be done to get the product ready and also the order (and therefore priority) of those tasks. The product owner must be capable of explaining the meaning of every single backlog item to other team members and to understand its value for the finished product.

Soft skills are: talking effectively with the customer and understand the requirements. The product owner has the final say in any decision related to his product and he is the single source of truth for the development team. He stays accountable for the success of the product. His job is also to measure the project performance. We’ll see later how this is done.

For smaller products this may be a part time job. The product owner is the link to management. He is respected by everyone and can delegate tasks to the team.

The Scrum Master

In any environment to the scrum team there is the danger that resources outside influence the teams productivity in a bad way. The Scrum Master has a communicative role, he must take care of the whole process and helps all members of the company to understand and follow the ideas of Scrum. This may mean help in understanding how to work with a scrum team from within other teams not following the agile approach. This may mean to coach team members and to manage the scrum workflow.

A scrum master can work part-time and can be part in more than one team. It is considered a management position in terms of “managing the process”. He ensures that Scrum is understood and enacted, he helps any team member with his knowledge in techniques and also helps the organization to adopt Scrum.

The Scrum Master is not a project manager nor a team leader but an organizator.

How these roles play together will be explained in the next blog posts when we will talk about scrum events and artifacts.

Basic Scrum Terminology

Before we dive into the depths of project management and working agile we will have to talk about a few basic terms, the scrum terminology. You will find it useful for understanding the blog posts to come.


At the most basic level, we have to define the word “Scrum” itself. One of the first theoretical approaches to agile methods was called “the holistic” or “rugby” approach, as the whole idea described the process to be performed by one cross-functional team across multiple overlapping phases and where the team “tries to go the distance as a unit, passing the ball back and forth”. In rugby football, a scrum refers to a tight-packed formation of players with their heads down who attempt to gain possession of the ball. Later, this term was used for a set of best practices in software development.

The Team

“Scrum” is done by teams, a bunch of people working together, each with a role within this team. We will talk about this aspect shortly.

The Sprint

The team follows a fixed schedule, called “the sprint”. The sprint is the most basic unit of work within the framework and it is repeated until development comes to an end. The duration of a sprint is fixed and consists of the same steps in each iteration. Those steps are basically “planning”, “work” and “review”. Details can be found in the appropriate blog posts later.

The Backlog

The work to be done is defined in a list of tasks, the “product backlog”.

The Agile Manifesto

In February 2001, 17 software developers met at the Snowbird resort in Utah to discuss lightweight development methods. They published the Manifesto for Agile Software Development, in which they said this:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

  • Individuals and interactions over processes and tools.
  • Working software over comprehensive documentation.
  • Customer collaboration over contract negotiation.
  • Responding to change over following a plan.

That is, while there is value in the items on the right, we value the items on the left more.

Let’s look at this in more detail:

Individuals and interactions

Self-organization and motivation are two important factors to success and so are interactions between all the people like co-location and pair programming.

Working software

To show a customer some piece of working software is more useful and welcome than just presenting plain documents to clients in meetings.

Customer collaboration

Requirements cannot be fully collected at the beginning of the software development cycle, therefore continuous customer or stakeholder involvement is very important.

Responding to change

There will always be change. This may be a thing you’ve learned the hard way. Agile methods are focused on quick responses to change and continuous development.

Furthermore, the Agile Manifesto is based upon twelve principles:

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  2. Welcome 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.

We will see later what those principles stand for and why they are important. But also pause a moment and think about all those principles, try to map the values described here to your day to day work. While they sound simple (and, more than that, reasonable), there must be a reason why most likely the developer reality is different to the ideas presented here.

An introduction to Agile

Basically there two ways to handle software projects. You can act predictive or adaptive. While the predictive way was common for years (and still is), the adaptive approach has gained momentum over the last decade. In this series we will talk about adaptive, so called “agile”, methods.

The difference between predictive and adaptive

So what do we mean when talking about “predictive” and “adaptive”? Long story short: the first approach tries to gather all information about the project upfront and derives a plan from the start until the end. Adaptive methods work with the premise in mind, that things change and that you cannot plan too far into the future. So while you have the idea what the project should produce, it only plans for shorter periods of time and constantly reevaluate the state.

Sometimes it’s even not possible to define the requirements of a project upfront. Agile methods come in handy here as they allow the team or the company to produce a lightweight prototype and to improve it over time. The predictive method will have many change requests by the customer or other stakeholders and therefore you will lose time and money as well as software quality.

Here, a main principle of agile comes into play: acting iteratively and adapt easily to the situation. This requires feedback and therefore something for the customer to see so he can understand and provide valuable feedback. Often the customer isn’t able to understand a partially working software solution. For developers, this is sometimes hard to understand, but many people must see something in order to fully understand it. Even more if we talk about abstract concepts like software design.

The benfits of agile

Agile methods aim to provide working software after each development cycle. We will talk about this later when we will talk about Scrum in more detail. Let’s just keep it simple for now by saying that working agile means working iteratively and incremental. They add new features and bug fixes over a discrete time interval and end up with a working piece of software.

But we can’t talk about Agile without talking about the Agile Manifesto. We will do so in the next part of this series.