Skip to main content

Sprint Retrospective technique – Timeline

Here I’ll look at one of the practical techniques you can use to promote discussion and learning in your Sprint Retrospectives.

 

A timeline retrospective allows the team to inspect how well the Sprint went, over a period of time. First, you will need a set of axes that represent each day of the Sprint. If you imagine the diagram below, but without the coloured cards.

Adding cards

Each team member will have cards in the colours above and they write down the events that occurred, on the appropriately coloured card. They then attach the card to the board so that it corresponds to the time that it occurred during the Sprint.

 

Drawing Conclusions

The chart provides an excellent visual representation of the Sprint and allows the team to easily see what went well and what could be improved. It also allows us to discover if certain events lead to other events – perhaps a significant event lead to a series of problematic events. Or there may be a cluster of good events around a particular time period.

Either way, the team can discussed these points and learn from them.

This chart could also be compared to the burndown chart for the Sprint. Does the velocity of the team increase when it experiences good events?

 

Actions

Based on the discussion, the team should identify actions they can take in order to improve in the next Sprint.

The Agile Manifesto

In February 2001, 17 individuals came together and wrote the Agile Manifesto, which says:
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.

© 2001, the Agile Manifesto authors. This declaration may be freely copied in any form, but only in its entirety through this notice.

 

The Agile Manifesto in detail

But what does all of the above mean when it comes to carrying out Agile methodologies in practice? Let’s look at each point in turn – as our team use Scrum, that’s the framework that I will use for reference.

 

Individuals and Interactions over processes and tools

In Scrum, the team is all. They must work together to plan Sprints, estimate, do the work – the list goes on. There should be effective interaction both within the team and with individuals outside it so that the Scrum team can establish a good quality Sprint Goal and work towards it.
Regardless of who the interactions are between, the most important aspect is to ensure free flowing communication. This can be achieved by:

  • Creating a blame free culture
  • Ensuring individuals are able to speak up (see planning poker and silent writing)

 

Working software over comprehensive documentation

The aim of each Sprint is to produce a working increment of potentially shippable product. Agile values an increment of working software over large amounts of documentation which likely provide no business value.

documentation
Comprehensively planning and documenting user requirements don’t give you anything of business value. It’s only when an increment is developed, that we get a return on investment.

However, we still need to create documentation as long as it doesn’t interfere with the development of the increment. I would also say that user guides, for example, can create business value – without it, users may be unwilling to use your product.

 

Customer collaboration over contract negotiation

Only by collaborating with your customer can you understand what they want. You might think you know what they want, and you can even suggest this to them. But ultimately, you need to build a product that has the features they require.

This is even more important in Agile, where we focus on adding features that will add business value. The Product Owner (acting as a proxy for the customer) doesn’t want extraneous features adding, just because the development team thought it’d be cool. I’ve seen examples of this and it’s a perfect way to really annoy your customer.

collaboration

I would say that once you start to have an idea of requirements, this can be put into a contract. But the contract needs to allow for changing requirements. If we were doing Waterfall, the contract would be set in stone, alongside the requirements, at the start of the project.
But we’re doing Agile, we expect the requirements to change, so that contract needs to account for this.

The beauty of Agile is that the requirements will naturally emerge as the project progresses. The customer sees the increment during the Sprint Review and this allows them to feed back on what they like and what isn’t as they expected. This feedback is then used to adapt the increment in the next Sprint.

Underpinning all this is communication. If the developers aren’t sure what the customer wants, then ask the customer.  If you ask them straight away, you can prevent minor issues from growing into large problems.

 

Responding to change over following a plan

In the Waterfall model, we create detailed plans right at the start of the project. But this is the time when we’re least equipped to plan – we don’t know enough about what’s required from the product. Once you realise that change is required, it’s often too late.

plan

Agile accepts that requirements will change and emerge as the project progresses. We do plan in Scrum, but it’s a continuous process. By utilising relatively short timescales (the Sprint) we are offered more frequent opportunities to inspect the product and adapt it.

If a plan isn’t working, then why stick to it? Look at why it isn’t working (inspect) and change it (adapt) based on past experience.

We also ensure that we don’t plan too far ahead. If we plan too far in advance, by the time comes to implement the plan, the product and environment are likely to have changed, rendering the plan useless.

 

Conclusion

When working on a Scrum project, it’s important to try and keep the Agile Manifesto at the back of your mind. Think to yourself:

  • Are my interactions with others adding value or are they causing impediments?
  • Do we need this amount of documentation or can we take advantage of “Simplicity – the art of maximising the amount of work not done”
  • Are we effectively collaborating with the customer?
  • Is our plan working, and if not, why not? Are we able to inspect and adapt it? Are we planning too far ahead?

 

Read the original Agile Manifesto, and get translations, here.

Scrum Events – The Sprint Review

The Sprint Review meeting takes place at the end of the Sprint. It allows the product increment to be inspected by the stakeholders and for the Product Backlog to be adapted by adding new items or rearranging existing ones.

The Sprint Review meeting is timeboxed to 4 hours, for a 1 month Sprint.

The meeting is attended by the whole Scrum Team, plus any stakeholders who have been invited by the Product Owner. First, the Product Owner explains which Product Backlog Items (PBIs) have been Done and which have not been Done.

Following this, the Development Team discusses what went well, any problems they had and how these problems were overcome.

Then the Development Team demonstrates the work that has been Done and answers questions. This is intended to be an informal demonstration, typically without the use of PowerPoint presentations. The presentation allows stakeholders to ask questions and give feedback on the increment.

sprint review meeting

During the Sprint Review, the Scrum Team should be able to demonstrate that the Sprint Goal has been met.

Following the demonstration, the Product Owner discusses the Product Backlog and may project likely completion dates based on the work completed so far.

The group takes a look at the overall timeline, budget and marketplace for the product, to give context for the next release.

 

The Scrum Guide also lists the following activities as part of the Sprint Review. In reality they are often moved to a separate event – Backlog Refinement.

  • The group collaborates on what to do next i.e. is the Product Backlog correctly prioritised or is it missing items?
  • A review of how changes to the marketplace have affected the work that needs to be completed next.

Estimating Product Backlog Items

The items in the Product Backlog each have an estimate of the amount of work required in order to complete them. This allows the Backlog to be effectively refined and managed.

Why Estimate?

  • Allow the Product Owner to properly prioritise the Product Backlog – they can only do this when they have a proper idea of the relative cost of items.
  • It enables high level forecasts to be made. The proposed story points can be plotted in the burn down chart.
  • The Product Owner can make better decisions around scope and schedule – i.e. how important is that ‘must have’ feature, now that it’s been estimated to have a large effort required to complete it.

planning poker

 

When to Estimate

Our team performs estimation of Product Backlog Items during the Backlog Refinement meeting.

The earlier you estimate, the earlier the Product Owner has information that can be used to prioritise the Product Backlog. You’re not held to the estimate – if more information comes to light, or the item changes, then the estimation can also change. It may also be useful to confirm that estimations are still accurate when items are pulled into the Sprint Backlog. Even though the time between the Backlog Refinement Meeting and Sprint Planning may be short, there is still the potential for Product Backlog Items to change or be clarified.

 

Why we estimate in points

Story Points provide relative values for the level of effort needed to complete a Product Backlog Item. They take into account:

Effort – the amount of work to do.

Risk and Uncertainty – how much or how little we know about the item.

Complexity – how complex is the logic that we have to work out or the code we have to write.

 

The final estimate will be a combination of these elements.

Have you ever given an estimate in hours and then overrun, even if only slightly? I’ll bet the next time you gave an estimate, you added on some extra time as ‘wiggle room’.
The issue with hours is that they’re absolute and provide a false sense of certainty.

With story points, the estimates are relative, so we don’t say how long a particular item will take, just that it requires, for example,  double the effort of another item.

It doesn’t matter what values we use, as long as they are relative. So an item with 2 story points is double the effort of an item with 1 story point.

 

Deciding on a scale – Fibonacci

Although you could just use 1,2,3, etc, this doesn’t really reflect the increasing effort required as the numbers are close to each other. Instead, we can use the Fibonacci numbers, where each number is the sum of the previous two e.g.

1, 2, 3, 5, 8, 13, 21…

Don’t pick too many numbers for your scale, but you might also want to include a large number such as 987 or infinity, for assigning to items that are too large to estimate.

 

How to estimate

Before you can start estimating all your PBIs, you need to establish a base story. This is the most basic item that you can find on the Product Backlog and one that everyone understands well. This item is assigned a story point value of 1.

You can also assign points to a number of other items, in order to give a range of base stories from the simplest to the most complex – these stories can be real or can be created specially for this task.

Below I’ll detail some techniques that you can use to estimate.

 

Planning Poker

Probably the most popular technique for estimating is Planning Poker.

First, decide on a ranking scale for items – as previously mentioned, the Fibonacci sequence is popular (1,2,3,5,8, etc).

In a group, every person has card for each of the ratings. You might also have cards with images, such as a cup of coffee – to represent when someone wants to take a break. Or something to denote when the discussion has gone off topic – I’ve seen a cartoon rat used, as in ‘going down a rat hole’.

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

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

If the selected estimates 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 estimate.

The same item is then estimated 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’ estimation, but one they can support.

 

T-shirt sizes

As an alternative to using numbers, some teams use t-shirt sizes (S, M , L , XL) to estimate. This can provide an easier way to get started, especially if teams are afraid to commit to a number as they are even more abstract. However they can cause some issues:

  • They will need to be converted to numbers at some point if you want to plot burn down charts.
  • People may have different views of the relative effort required for a particular size. So, is a Large item twice as big, or ten times as big, as a Medium task?

t-shirt sizes

 

Ordering

Each member takes a card representing a Product Backlog Item from the pile and adds it to the table. They position in it relation to how large they estimate the item to be – largest items go at one end of the table and smallest at the other end. The next person takes a card and places it on the table, in relation to all other cards. Or they can choose to challenge the position of an existing card. If they think it requires relatively more effort, it goes higher up the board, above the lower effort items.

Once all the cards are placed and the team are in agreement, the items are assigned an estimate using the Fibonacci scale. Starting at the smallest item, assign the card an estimate of 1. Repeat this for the next item up the table. Move up the table until you reach items that you would estimate as 2, then 3 and so on.

 

Conclusion

Once you’ve estimated the Product Backlog Items, the Product Owner can use those estimates to help them order the Product Backlog.

Over time, the teams’ estimates will become more accurate and they will have a better idea of what can be fit into a Sprint. This process can be sped up by utilising the Sprint Retrospective. The team looks at the estimates they gave for items on the previous Sprint and compares them to the actual amount of effort required. Using this knowledge, they can Adapt their estimation for the next Sprint.

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.

For

  • 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.

Against

  • 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.

 

MoSCoW

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 its 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

Mandatory
L
inear
E
xciter
Q
uestionable
R
everse
I
ndifferent

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

 

 

Initial

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.