Scrum basics: Retrospectives

Retrospectives are a frequently overlooked aspect of scrum.  Perhaps this is because they are “non-functional”, in the sense that they don’t contribute directly to the output of the team.  I maintain, however, that good retrospectives are the key to a highly functioning team.

What is a retrospective?

A retrospective is a meeting where the team get to reflect on their current progress and process and decide how they can improve it.

What does it mean to improve progress and process?

It can mean absolutely anything … the team get to decide.  Remember that the purpose of scrum is to build a team that can smoothly and effectively deliver business value on a regular basis.  Anything which gets the team closer to this goal counts as an improvement.

It’s also important to point out that it is the team themselves which decide how they can improve.  People such as managers, IT directors, agile coaches and so on can make suggestions, but the team needs to take ownership of their process.  This is what it means for a team to be “self-organising” … an agile term which is bandied around a lot and is often misused.  The self-organisation of a scrum team is the main points of retrospectives.

What’s the difference between a good and a bad retrospective?

Retrospectives, like a lot of things in agile, need to be judged on their outputs.  A good retrospective will produce improvements that address important issues the team is facing.  A poor retrospective will skirt around issues and address unimportant issues.

For instance, suppose a team is consistently releasing buggy software.  A good retrospective will attempt to address the bugs, both in terms of fixing outstanding issues as well as attempting the underlying cause of the bugs.  A bad retrospective would focus on other incidental issues, e.g. variable names not adhering to the agreed coding standards.

Poor retrospectives can happen for a number of reasons:

  • they may be unaware of how well they are meeting business priorities (e.g. they don’t know that their software is buggy)
  • the team may be unaware of business priorities (e.g. they may mistakenly think that the bugs have a minor impact)
  • the team might not care about business priorities (e.g. they don’t care about their bugs)
  • the team may be unwilling to talk about their problems
  • the retrospective meeting might get side-tracked into addressing low priority issues
  • … and so on

Some of these issues can be addressed by ensuring good communication between the team and the business.  Some of these issues can be addressed by being careful with the retrospective meeting and its format.  The retrospective meeting can be structured in such a way that it encourages the team to discover, explore and address their big issues.

What’s the format for a retrospective meeting?

There is no single format retrospective meeting, and there is no retrospective format which is best.  Retrospectives can take many forms.  In fact, the format of retrospectives should be changed from time to time, as this encourages people to think about their situation in new ways.  A great resource for ideas about different formats is Agile Retrospectives, by Esther Derby and Diana Larsen.  There are many other resources available on the web too.

What would you suggest as a starting point?

Here is a retrospective which I often use for teams that are new to retrospectives.  Please do not use this without thinking about it and deciding how it will fit your team.

1. Introduction

Some sort of icebreaker activity.  For instance, everyone gives one word that for them sums up the sprint. It can be accompanied by explanation or not. Questions are not allowed at this point, since people should be thinking rather than talking.

2. Review previous actions

Look at the actions from the last retrospective.  Decide which were completed, perhaps discuss how effective they were and decide which, if any, the team should carry on with.

3. Gathering data

Everyone writes post-it notes to fall into 2 categories - "What went well" and "What went not so well". The team gets 10-15 min to write the notes and then individuals take it in turns to stick them up onto a whiteboard. As they stick up a note they should introduce it to the team "I wrote xxx because I felt that ...". Some questioning is allowed here, but the point is really just to gather information.  The use of post-it notes is a great equalizer and prevents dominant characters from dictating the course of the meeting.

4. Extracting insight

The facilitator then looks to group up the post-it notes into topics / themes. For instance, there may be a number that relate to daily standup meetings. Put these in a clump.

5. Decide on actions

The team now decide on actions to address the items that didn't work well. Start with the biggest clumps of post-its, since those are the issues that are causing the most pain. Generally it's not worth trying tackle all issues. When you have 4-8 actions then call time. There should be lots of discussion and brainstorming during this part of the retrospective. All actions should be specific and should have an owner who is prepared to take responsibility to see it implemented during the next sprint. If nobody volunteers to own an action, then throw it away because clearly nobody wants to see it implemented.

Actions which cannot be implemented by the team are not allowed, e.g. “business users must stop changing their mind”.  Actions which are vague (e.g. “improve communication”) need to be explored more and made specific.

October 21 2011

Scrum basics: The product backlog

Scrum uses this term “backlog” – it has product backlogs and sprint backlogs and sometimes even technical backlogs – and the term really just means “a list of work”.  In common usage (i.e. outside of scrum) I think of a backlog as a bunch of stuff that you should have done already but haven’t gotten around to yet.  For instance “due to a computer problem, there is a considerable backlog at the airline checkin desk”.  So the term “backlog” can be slightly confusing, but as long as you think of “a list of work” then you’ll be fine.

Now the product backlog is really just a list of work that could be done on the product (where “product” equals “your software project”).  When the team does a sprint planning meeting, then they will take pick items from the product backlog and work out how they can deliver them.

Prioritisation and ordering

It’s a pretty well-established fact that developers can get side-tracked into building frameworks when they should be delivering application.  In order to reduce this risk, scrum allows the product owner to exert some control over which items the team choose for their sprint by ordering the product backlog a way that highlights what needs to be done first.  This helps the team to focus on the most important aspects and it tries to ensure that they don’t get side-tracked into doing areas that they think are cool but deliver little business value.

One of the most common scrum problems is a poorly ordered backlog.  This typically results in the product owner get annoyed with the team because they aren’t focussing on the important items.  Conversely, the team tend to get frustrated and disheartened because their work never seems to be appreciated.

What does a product backlog item look like?

Scrum leaves wide open the question about what exactly constitutes a backlog item, but it’s becoming common to make use of user stories.  These are short sentences that express what needs doing, the benefit of the new functionality and which types of user will be interested in it.

Does a product backlog item need a lot of detail?

Now user stories are great, and a well-written one can express a lot, but fundamentally they are just a single sentence.  And a single sentence is invariably too limited to fully express a piece of functionality.  As a result, the user story should be beefed up with some extra detail.  This extra detail can take the form of acceptance criteria, wireframes, screen mockups, additional descriptions or whatever.  This detail should be captured in the product backlog and stored against the product backlog item.

It’s important, however, to bear in mind one of the agile principles:


What this means with regards to product backlog items, is that you should try to have just enough detail.  Aiming to have loads of detail for each product backlog item is to miss the point.

What happens if there isn’t enough detail on a product backlog item?

This becomes an issue when the team tries to plan a product backlog item into a sprint and simply gets stuck because they don’t know what to do.  The best way to deal with this situation is to actually talk to the product owner (get them into the sprint planning meeting) and have them explain.  The additional can be captured if you like, but the important point is that the team should then be clear on what needs doing.

If the product owner is not available (a sad situation that happens all too often) then the team have a difficult choice.  They can either put off developing the functionality which they have been told is important, or they can make some assumptions about what needs doing.  Neither of these results is ideal.

To try and avoid this situation, the scrum master should be proactive and should be trying to get enough detail on upcoming stories before the sprint planning meeting starts.

Items get added to the backlog by the product owner

One of the great features of a product backlog, is that adding an item on it does not actually constitute a commitment to delivering that item.  After all, the product backlog is the list of work that could be done on the product.  Whether or not a given backlog item gets delivered depends on the prioritisation process.

Items get taken off the backlog by the team

Once a product backlog item is planned into a sprint, then it gets removed from the product backlog.

Product backlog items can get modified by the product owner at any time

The product owner is free to adjust any of the items on the product backlog at any time.  He / she can remove items, change them and adjust prioritisation at any time.  None of this will affect the team’s current sprint, because the items that they are currently developing have been removed from the product backlog.  Instead, these changes will be taken in consideration by the team at their next sprint planning meeting.

It’s worth remembering that scrum does not actually give the product owner the ability to change product backlog items once the team has planned them into a sprint.  The product owner can call an abnormal sprint termination, but this is not the same as changing the description of an in-progress piece of work.

Storing the product backlog

Excel (or even Word) can be used for holding the product backlog, and there are a variety of commercial products out there which claim to make life easier.  The important thing to bear in mind is that, as with any software tool, the tool must fit the process.  This means that the product backlog must be easy to access and read, however it’s stored.

Predicting delivery progress

This will be the subject of a number of future posts.  Suffice it to say, that it is possible to make predictions about when the items on the product backlog will get delivered by the team.  Concepts such as story pointing, team velocity and release planning are relevant.  Of course all such predictions are subject to change … after all, this is an agile process we are talking about!

September 1 2011

Scrum basics: Sprint planning meetings


When a developer starts work on a new piece of code or application for a hobby project, they generally have a rough idea of the design and how long its going to take. Scrum has taken a pragmatic approach and designed the sprint planning meeting to fit exactly that; a dialog of essentially the what's and the how's.


The time within a sprint is fixed based on the iteration length, however people’s time per iteration can change based on holiday and having resources allocated elsewhere. In order to scope out what PBIs we will put into the sprint, we need to calculate how much time we have to work with.

Assuming you have:

  • 5 days in your iteration.
  • 8 hours per day per team member.
  • 3 team members.
  • 1 team member is on holiday.

Then you have 80 hours of potential time this sprint to burn down tasks. A general rule on previous projects is that people are not machines and are not productive for 8 hours a day. Cutting this value down to 5 productive hours a day means you have 50 hours of potential time, it may look bad on your spread sheet but your project is more likely to succeed because of it.


Before a sprint can begin, a team needs to know what is going to be worked on. At the beginning of the meeting the product owner should bring in the prioritised backlog of work and work with the team to bring items into the sprint. This dialog needs to happen for two reasons:

  1. So the product owner communicates the priority of the tasks and what order they should be completed in.
  2. So the team can negotiate re-ordering tasks to tackle tasks more efficiently, usually because of technical reasons.

Exploring the latter point further, a common scenario is:

  • A solution comprises of multiple systems, a frontend and a backend.
  • The business priority puts the frontend system first.
  • Data can only be displayed on the frontend by using the backend.
  • They both need to be completed for go live.

The options are:

  • Create a throw away tool to push data to the frontend.
  • Implement a small slice of the backend.

So even though the business priority puts the frontend first, its more economical from a technical perspective to reorder some of the tasks. This is what the initial part of the sprint planning meeting is about, optimising the way the team will work over the sprint and providing the best value possible to the business.


The last part of sprint planning is the estimation, which involves:

  • Picking a PBI from the top of the prioritised list.
  • Breaking it down into tasks.
  • Assigning hours (estimated) to those tasks.

What you will find during this is a vast about of discussion which will encompass business logic, lots of conceptual design, some logical design and snippets of physical design. This entire dialog drives and shapes what will happen in your sprint, so its important to strike a good balance between allowing the team to communicate and time boxing the session so the team doesn’t burn out.

After the team is satisfied about what the task involves, an estimate of the effort involved in hours should be assigned. All team members should pick a number, either on cards or their fingers and come to a consensus after a little more discussion. A good rule of thumb for the size of the tasks is that they should be small enough to be completed within a day; smaller tasks drive better more accurate estimates.

It’s important that the product owner is available during this in case the team has questions about solutions they believe need approval from the business. They can also assist as an expert in the domain of the project along with business analysts during discussions around business rules and logic.

Begin your sprint

Once you have estimated enough tasks such that your availability figure is exceeded you are ready to begin your sprint.

Scrum basics: The sprint

In Scrum, iterations are called sprints and they are the most important rhythm in the project.  They start with a sprint planning session and end with a sprint review and a sprint retrospective.  Here are some further attributes of a sprint:

  • fixed in length – a sprint must have a defined start and end date … release dates might slip, but a sprint end date shouldn’t
  • fixed in scope – the work to be done in a sprint must be clear and well-understood before the sprint starts

These two points play nicely into the concept of the Iron Triangle of software.  Simply put, the Iron Triangle asserts that you can control two factors in the diagram below, but attempting to control all three will typically lead to failure.

iron triangle

What we can see is that we are fixing time and cost and as a result, it is scope which is variable.  This is an important point and one that is not often appreciated.  If your project has a scope which is fixed and cannot be changed, then Scrum may not be the best choice.  Agile processes are good at adapting to changing and emerging requirements, not at hitting a fixed set of deliverables over a long time period.

And now to some more detailed points relating to sprints:

Sprints must be regular

As I said at the start of this post, sprints form the basic rhythm of the project.  As a result, they need to be regular and all the same length.

This is not to say that a project cannot change it’s mind about sprint lengths.  I’ve been on projects where the team has decided to vary the sprint length, with a view to improving it's velocity, and this was fine.  However, irregular sprint lengths should not be something that the team has to endure.

Sprints must be short

A sprint should represent the maximum length of time for which requirements can be fixed.  If business users cannot commit to 4 weeks of stability, then sprints should be 2 weeks.  If business users cannot commit to 2 weeks of stability, then sprints should be one week.  If business users cannot commit to 1 week of stability, then you have some big issues and applying Scrum to your software development is unlikely to address them!

I’ve never heard a good reason to have sprints longer than 4 weeks.  And my personal preference is to have sprints of 2 weeks.  In my experience, this has a number of benefits:

  • the team remains focussed since the end of the sprint is always typically close … 4 week sprints can result in a dangerous lull of activity during the first week or two
  • requirements can usually be fixed for a 2 week period

Sprints should finish on a Friday

The team will typically focus a lot of energy towards the end of the sprint and having a few days off after the end of a sprint is very refreshing.  The alternate situation is that the team finishes a sprint, possibly making a bit of a push to get over the line, and then has to start sprint planning the next day.  I always find sprint planning to be the most demanding activity in Scrum, so starting it immediately after the end of a sprint feels a lot like unnecessary hard work!

The output a sprint is essentially unknown

This follows from my earlier point that scope is allowed to vary.  The project team will, during sprint planning, use various techniques to work out how much work can be achieved during the sprint.  This set of work becomes the goal for the sprint.  However, the team may or may not actually get all of the work done.  After all, as a famous physicist once said “Prediction is difficult … especially about the future”.

Success means meeting sprint goals

A successful sprint is one in which the team delivers its sprint goals – this is the definition of success for a sprint.  A successful team is one which regularly has successful sprints.  Conversely, a team which regularly misses its sprints goals is unsuccessful and has issues that need to be sorted out.  These issues can sometimes be identified and resolved during project retrospectives, but sometimes teams are either stubborn (refusing to change) or myopic (they fail to see the issues) or dumb (they fail to see the problem).  In these cases, external scrum coaches can often help the team through their issues.

Sprints can be terminated abnormally

The situation can sometimes arise where business priorities shift dramatically during a sprint.  In these cases it may be futile or even harmful for the team to continue with the sprint.  If this is the case, then a sprint can be terminated.  Any work in progress should be destroyed and not committed – we do not want half-finished work in the project and it is not clear when the team would complete this work (if ever).

August 19 2011
Older Posts