Skip to main content
Do you need web development services?

Scrum Events – The Daily Scrum

The Daily Scrum is time-boxed to 15 minutes and allows the Development Team to synchronise their activities and create a plan for the next 24 hours.

The Daily Scrum should be held at the same time and place every day – the consistency reduces complexity.

Only the Development Team participates in the Daily Scrum. That is, only they talk. Other people are allowed to attend the meeting.


Daily Scrum


Should the Product Owner attend the Daily Scrum?

There are arguments both for and against the PO attending the meeting.


  • It increases Transparency, so the PO can keep up to date with the progress of the increment.
  • The Development Team can question the PO about Product Backlog Items in order to clarify them.


  • The invisible gun effect – even if the Product Owner doesn’t try to influence the meeting, the presence of someone with power and status can negatively affect the self-organisation of the team. Team members may be less likely to say what they really think.


The Three Questions

At the Daily Scrum, the Development Team members each answer three questions:

  1. What did I do yesterday?
  2. What will I do today?
  3. What impediments do I face?


The Daily Scrum allows the Development Team to Inspect their progress towards the Sprint Goal. The team are only reporting to themselves, not a Boss, and it’s a great way to monitor this. It also highlights areas where a team member may be struggling and enables the team to Adapt to this.

The Scrum board can be updated before or during the Daily Scrum. It is interesting how an action as simple as moving a card on a board, can motivate the team and provide a real feeling of ownership of the work and the resulting Increment.

The team can additionally meet after the conclusion of the Daily Scrum,  in order to discuss any issues or plan in more detail.

Product Backlog Prioritisation Techniques

Two of the Scrum Masters’ responsibilities to the Product Owner are:

  • Finding techniques for effective Product Backlog management;
  • Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value;

So let’s look at a few practical techniques for prioritising/ordering the Product Backlog.

I have focussed on qualitative methods here as I find they are the easiest for Product Owners and stakeholders to quickly pick up. Of course each person will have their own agenda when it comes to their ‘must have’ features and these features are always the most important to that individual. But people will always have a bias – I have even heard of quantative results being overruled because they did not fit with what the managers at the organisation wanted – so perhaps it is better to accept this fact, rather than pretending you’re prioritising objectively.



Using this method, Product Backlog Items are categorised into one of the following:

Must have – these must be included in a product for it to be regarded as a success.
Should have – high priority items that should be included wherever possible.
Could have – lower priority items. These are generally ‘nice to have’.
Won’t have – items that won’t be implemented at the current time. However they can be reconsidered in the future.

Within each category it may be useful to further order the items.


Buy A Feature

Using the concept of gamification, this method can make prioritisation more fun, while still discovering what the stakeholders want. Simply follow these steps:

  1. Provide a cost for each item that needs prioritising. This may be based on developer effort, complexity or actual cost to develop.
  2. Get the stakeholders together – this works best if they meet in person.
  3. Present to them the items that need prioritising.
  4. Each stakeholder has an allowance of money e.g. £100
  5. Stakeholders assign their money appropriately to the features that they want. They can buy individually or club together with others in order to buy more expensive items.
  6. Items can be bought more than once, by different stakeholders.
  7. The items can then be ordered by the amount that has been spent on them – whether this is low cost items that have been bought many times, or more expensive items that people have collaborated to buy.


Priority Poker

This works in the same way as Planning Poker. First, decide on a ranking scale for items – the Fibonachi sequence is popular (1,2,3,5,8, etc).

In a group, every person has card for each of the ratings.

The item to be ranked is read out to the group and each member selects a card based on their perceived priority. They must keep their card hidden until everyone has chosen.

Once every member of the group has selected a card, they are all revealed simultaneously.

If the selected priorities are all similar, then the group is in agreement. If there are outliers, then the differences must be discussed in the hope of aligning everyone’s views on the required priority.

The same item is then ranked again by repeating the steps above in the hope of achieving consensus. If consensus still can’t be reached it may be that the item needs refining into smaller items or that an average (median) score is used.

Alternatively the group may need to decide not on the ‘perfect’ priority, but one they can support.


Kano Model

The Kano model challenges the idea that improving every aspect of your product results in an increase of customer satisfaction. In reality, there are areas of basic expectation in a product that a customer would always expect to be there – often these can require a large amount of effort to develop. Conversely, there maybe features that would impress users but require very little effort to create.

Mandatory features – must be present in order for users not to be disatisfied

Linear features – the more of these there are, the more satisfied a user is

Delighters – Features that are high up the satisfaction scale.

The Kano model is a little more in depth than the other methods of priorisiation that I’ve mentioned, so I’ll put it into it’s own post. That way we can look at it’s theory in detail and see how we can use it practically when prioristing the Product Backlog – Using the Kano Model to prioritise the Product Backlog.

Kano Model – Product Backlog Prioritisation

The Kano model challenges the idea that improving every aspect of your product results in an increase of customer satisfaction. In reality, there are areas of basic expectation in a product that a customer would always expect to be there – often these can require a large amount of effort to develop. Conversely, there may be features that would impress users but require very little effort to create.

Categories of features

Basic features – must be present in order for users not to be dissatisfied.

Indifferent features – Features that don’t affect a customers’ satisfaction one way or the other.

Linear features – the more of these there are, the more satisfied a user is.

Delighters – Features that are high up the satisfaction scale.


We can’t create only features that are high in satisfaction. This is because of the Functionality dimension, which represents how well a feature has been implemented, how much has been completed or how much it cost to develop.

Kano chart

The Four categories of Features

Basic/Mandatory features
Features that users expect to exist in a product are unlikely to score highly on satisfaction, but developing them can be costly. But if a basic feature doesn’t exist, users are likely to complain.

For example, a basic feature for a hotel would be ensuring 24 hour hot water. They require large expensive boilers (with associated fuel usage) that can supply instant hot water. The hotel must spend huge amounts on ensuring the hot water is available, but users will never get excited by it because it’s something they expect.


Indifferent features
Features that don’t really affect the satisfaction level of users. So no matter how much effort is put into developing them, it won’t make any difference to the happiness of your users. Because of this, think carefully about if you should be developing these features.


Linear features
The more you provide, the more satisfied users become. For example, battery life of a mobile device.


Delightful features
These are features that score highly on satisfaction, but may only take a small effort to create. If they aren’t present, a user is unlikely to complain. But if they are present, they will be delighted by the product.

Going back to the hotel example, providing guests with a free drink probably only costs a few pence, but is likely to score highly on satisfaction.


Delight changes to Basic

Over time, features that were originally classed as Delighters, will change to Basic features. For example, once users start to expect a free drink on arrival at their hotel, they will become dissatisfied if they were to no longer get the drink – it has become a basic feature.


Using the Kano Model to prioritise the Product Backlog

To discover how users see our products’ features, we conduct a Kano questionnaire. For each feature, we ask two questions:

  • Functional – How do you feel if this feature is present?
  • Dysfunctional – How do you feel is this feature is absent?

For each question, the user may answer with one of the following:

  • I like it
  • I expect it
  • I am neutral
  • I can tolerate it
  • I dislike it

Their answers can then be categorised using the following grid:

kano grid


So if a user answers the functional question with “Like” and the dysfunctional with “Neutral”, the feature will be classed as E, or Exciter.

You’ll notice we also have two new categories:

Questionable – these occur when the user gives conflicting answers e.g. like for both answers. This suggests there’s something wrong with what you’re asking.

Reverse – this suggests the user actually wants the opposite of what we’re suggesting for the feature.


Once your users have completed the questionnaire, you can aggregate the results. For each feature, add up the responses in each Kano category. The category for a particular feature is the one with the largest amount:

kano results

So we can see that login using Facebook is a Mandatory feature, upload a photo is Linear, and share photo with friends is an Exciter.

When it comes to prioritising the Product Backlog, you need to include the Mandatory items as your highest priority, followed by Linear and then Exciter.

Our Definition of Done

This post is just to record our teams’ definition of Done and track it as it changes over time.

Our Current Definition of Done

Code compiles

Code Peer Reviewed by one other Developer

Tested by the Development Team

User Acceptance tested

Approved by User Interface expert




Code compiles

Code Peer Reviewed by one other Developer

Tested by the Development Team

User Acceptance tested


Update 1

Approved by User Interface expert

Scrum Events – Sprint Planning

The development work that will be completed during the Sprint is planned at the Sprint Planning meeting and involves the whole Scrum Team.

If your Sprint is a month long, then the Sprint Planning is time-boxed to 8 hours. If you have a shorter sprint, then the time-box is reduced relatively.


sprint planning process


In Sprint Planning the aim is to essentially answer two questions:

  1. What will be delivered in the Sprint?
  2. How will we do it?


What will be delivered?

The Product Owner discusses what they’d like to achieve from the Sprint while the Development Team looks at which Product Backlog Items (PBIs) can be implemented in this Sprint.
Only the Development Team select the PBIs that will be worked on, as they know best what they can achieve.

The whole team collaborates to create the Sprint Goal – a high level objective that will be met when all the PBIs for this Sprit are implemented. The Sprint Goal provides guidance to the Development Team on why they’re building the Increment. It also gives the Development Team flexibility on how the Increment will be delivered – they commit to achieving the Sprint Goal, not the PBIs.


How will we do it?

The Development Team discusses how it will create the Increment.

Product Backlog Items + a plan for delivering them = Sprint Backlog

The Development Team will break down the PBIs into much smaller tasks, of around one days’ effort or less.
A plan for the whole Sprint doesn’t have to be created here – the team only needs to plan work for the first few days of the Sprint. The later work will be planned as the Sprint progresses.

The Development Team can discuss the PBIs with the Product Owner in order to clarify the requirements, and can renegotiate with him if they have too much or too little work.
They can also invite additional people in order to provide technical or domain knowledge.

“By the end of the Sprint Planning, the Development Team should be able to explain to the Product Owner and the Scrum Master how it intends to work as a self-organising team to accomplish the Sprint Goal and create the anticipated increment.”
– Scrum Guide


When to estimate

I often see confusion around when PBIs should be estimated and each team does it differently. Some estimate PBIs and not tasks, some estimate both PBIs and tasks and others estimate tasks but not PBIs! Below is the way we do it, but remember to Inspect and Adapt to see which way is best for you.

  1. PBIs in the form of user stories are estimated in Story Points during the Backlog Refinement Meeting. This gives the Product Owner an additional metric to use when ordering the Product Backlog.
  2. As the PBIs are already estimated, when it comes to Sprint Planning, the Development Team can focus on selecting the appropriate items for the Sprint.
  3. Before we estimate the effort required, we define the acceptance criteria for a task. This ensures the Development Team knows what’s required to complete the task and allows them to more accurately estimate.
  4. Once the PBIs have been split into tasks during Sprint Planning, we then quickly estimate these tasks. At this point, many teams will switch to estimating in hours, but I don’t agree with switching metrics. So we again estimate in Story Points. Most of the time Development Teams members will be in agreement on the estimate for a task, but occasionally there will be a larger difference. This can be useful in highlighting technical issues that not everyone has thought of.
    As the team matures, it’s possible that they can do-away with estimating individual tasks.

We’ll look at the whole process of estimating, and the different techniques you can use to perform it, in a later post.

Scrum Glossary – INVEST

How do we know if a Product Backlog Item is of a good quality? We need to make sure it’s not too large to be implemented in a Sprint and that it can be tested in order to say that it’s Done.

To help us ensure a PBI is of good quality, we can use INVEST:

Independant – the PBI should be self-contained and not depend on other PBIs.

Negotiable – the PBI is not an explicit contract and should be open for discussion.

Valuable – it must deliver some form of value to the business

Estimable – the development team must be able to estimate how much effort it will take to implement the PBI.

Small – the PBI must fit within a Sprint.

Testable – we must be able to define tests/acceptance criteria for the PBI so that we know when it is Done.

Scrum Glossary – acceptance criteria

Acceptance criteria are used to define when a task is completed. They allow you to meet the Testable aspect of user stories when using INVEST.
They can cover both functional and non-functional criteria.


Example Acceptance Criteria

If we take the following as our user story:

As a registered user, I want to book onto a training course of my choice.


Some possible acceptance criteria could be:

  • Send confirmation email to user when booking is saved
  • Display correctly on PC, tablet and mobile phone.
  • The form cannot be submitted without entering all required data.

Acceptance criteria are specific to a user story, while the Definition of Done covers all stories.

Scrum Events – The Sprint

Events in Scrum are used to create consistency and reduce the need for additional meetings that aren’t part of Scrum.
All events are time-boxed, so they have a maximum duration – the length of the time-box depends on the length of your Sprint.

The Sprint is essentially a container for all the other meetings and the development work. The other meetings provide opportunities to inspect and adapt the process.



Scrum process diagram

The Sprint

With a maximum time-box of one month, the Sprint is where the development work is completed, with the result being a “potentially shippable software increment”.

Potentially shippable means that the Product Owner may decide that the software can be released to the customer.
However, it doesn’t have to be released.

An increment is a small slice of software functionality, that can be added on to all the previously released increments.

But how do we know if the software is in a shippable state? That’s where “Done” comes in.

Scrum team members should have a shared understanding of what “Done” is, and this should also be shared between teams.

“Done” signifies when a Product Backlog item is complete.


Example Definition of Done

Each team will have its own definition, but here’s some examples of what you might include:

  • Code builds without errors
  • Code peer reviewed
  • Unit tests pass
  • User acceptance testing passed
  • Approved by Product Owner

As the Scrum Team progresses, it’s likely that the definition will become more strict.


The Sprint contain the Sprint Planning meeting, daily Scrums, development work, the Sprint Review and the Sprint Retrospective. There’s also the unofficial Backlog Refinement meeting which isn’t part of the Scrum Guide, but many teams find it useful to conduct.

No changes should be made during the Sprint that might endanger the Sprint Goal.

Sprint Goal

  • A high level objective for the Sprint that is met by implementing the Product Backlog Items.
  • The Team commits to the Sprint Goal rather than the PBIs.
  • The Sprint Goal provides guidance on why the Team are doing the work and allows flexibility around how the solution is achieved.

Also, quality goals should not decrease, although the scope of the sprint can be clarified and altered following discussion between the Product Owner and the Development Team.

Sprints last for a maximum of one month, but you may find it useful to use a shorter time-box. Shorter Sprints allow the team to more readily adapt to changing requirements, but make sure the Development Team has enough time to create software of value.

Shorter Sprints also reduce the risk if a Sprint is cancelled – the team has only ‘wasted’ the time in that Sprint and not any more. Additionally, they allow for more frequent inspection and adaptation, enabling the team to see more consistent progress towards a goal.


Cancelling a Sprint

Only the Product Owner has the authority to cancel a Sprint, but they can be influenced by stakeholders or the Development Team.
Cancellation usually occurs when the Sprint Goal becomes obsolete e.g. the feature is no longer required.

If the work that has been completed is in a shippable state, then the Product Owner can accept it. The rest of the work is put back into the Product Backlog.


A Sprint ends when the time-box expires and the following Sprint starts immediately (In practice this is usually the next working day).

What are the Roles in Scrum?

Scrum teams consist of a Product Owner, Scrum Master and the Development Team. Scrum teams are self-organising and cross functional.

Self-organising means that the team itself decides how to best complete the work, rather than being told by someone outside of the team.

Cross functional means the team has all the skills required to complete the work.


product ownerProduct Owner

The Product Owner (PO) is responsible for maximising the Return on Investment of the product development and this is usually done through the prioritisation of the Product Backlog Items.

The PO is the business contact for the team – they will liaise with stakeholders within the business to determine their desires for the product. However, only the PO can decide on the priority of these items.

The PO must also ensure that Product Backlog Items are clearly understood by the Development Team and has the final say on requirements decisions.


development teamDevelopment Team

The Development Team does the work to build a potentially shippable product increment every Sprint. They are self-organising, so only the team themselves decide how to create the increment.

They are also cross-functional so that the team has all the required skills to complete the work.

All members have the same title of Developer, so although members may have specialised skills, the team as a whole are responsible for all of the work.

Development Teams should have 3-9 members. Less than 3 makes it difficult to complete enough work within a Sprint, while more than 9 increases complexity.


scrum masterScrum Master

The Scrum Master is a servant-leader for the Scrum Team. They have a variety of responsibilities, which can be seen in full in the Scrum Guide, but the most important of these are:

  • They facilitate the work of the team by ensuring Scrum practices are understood and followed.
  • Protect the team from distractions such as stakeholders trying to sneakily get their feature worked on first.
  • Remove impediments.
  • Enforce time boxes.

The Scrum Master is not a Project Manager. A Project Manager runs the project and team, and is accountable to the business for completing that project. They may set work for team members, prioritise features and manage risk.
A Scrum Masters’ role is to facilititate the process and the team. Their accountability is to the Scrum process.

Scrum Glossary: Scrum

What is Scrum?

Simply put, Scrum is an Agile framework for developing complex products.

While it is often used for developing software, it can be used for any complex products, especially where requirements are not known or may change frequently.

Right at the start of a project we know less than we’ll ever know about the requirements. Scrum accepts this and doesn’t try to define all the requirements up front – like you would do in the Waterfall method. Instead, Scrum uses an empirical approach of Transparency, Inspection and Adaptation.

  • Transparency – the people involved in the Scrum process should be able to easily see the state of the process and the artifacts involved.
  • Inspection – looking at the process to determine what went well and what could be improved.
  • Adaptation – based on the results of Inspection, we make changes so that the Scrum process runs more smoothly next time. This way we are constantly and iteratively improving the process.

So requirements are discovered and refined as the project progresses.

Scrum aims to regularly release potentially shippable software increments using a series of meetings, with associated roles and artifacts.

We’ll look at these in more detail in subsequent posts, but the basic process is as follows:


Scrum process diagram


  1. The Product Owner creates a prioritised list of product features they’d like. This is called the Product Backlog.
  2. At the Sprint Planning meeting, the team takes a selection of these features from the top of the list to create the Sprint Backlog.
  3. These features are what they think can be completed during a Sprint – a 2-4 week period of development.
  4. The Development Team works to create the product increment.
  5. The team meets daily at the daily Scrum, where they report on progress.
  6. The Scrum Master helps to coach the team in the whole process, while removing impediments that they may encounter.
  7. At the end of the Sprint, the work we have completed so far should be potentially shippable I.e. Released to customers.
  8. Following this, the Sprint Review meeting allows the Stakeholders to view what was completed during the Sprint and for the team to discuss any issues they had. It also enables the Product Backlog to discussed.
  9. The Sprint Retrospective meeting allows the team to Inspect the Sprint to identify any issues and what can be improved.
  10. Backlog Refinement isn’t an ‘official’ Scrum meeting, but many teams find it useful. It ensures the Product Backlog accurately reflects the Product Owners needs by removing, creating and prioritising User Stories.