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

Scrum basics: The process

As the start of my new series looking at the basic elements of Scrum, it seems best to start with the end … the end goal.  The end goal of Scrum is a team which is smoothly and effectively delivering business value on a regular basis.  Some will say that this is the goal of most, if not all, methodologies, but Scrum is the most effective in achieving this goal IMO.  As a developer, it is also the methodology which I have found to be the most fun!  But more on that later.

Now Scrum is really a pretty simple process to follow and there are a number of resources around on the web which can supply details.  What I’m going to try and delve into is not only the basic rules and mechanisms of the process, but I will give you advice from my experience on the things that do and don’t work.  As with all advice YMMV.  During the series we will be straying into human psychology, communication methods, testing methodologies, user-centred design and a number of other topics that may look unconnected, at first glance.

The basic parts of scrum are:

Some specific further topics which merit some discussion are:

  • Burndown charts
  • Taskboards
  • User stories
  • Team velocity
  • Release planning
  • Continuous integration
  • Variations on the estimation process

I’ll link from here to my posts, as they’re published.

August 17 2011

Replaceable resources in Silverlight

Some time ago I faced a requirement where I needed to be able override my Silverlight resources at runtime, and here’s how it got implemented.  All the resources that we wanted to be able to override got moved into a specific ResourceDictionary, which was brought into the App.xaml resources through a MergedDictionary.  Then at runtime, the following code would be executed:

public void LoadResourcesFromServer()
    DownloadStyle(new Uri("../ClientBin/brand/CustomizableResources.xaml", UriKind.Relative));

private void DownloadStyle(Uri downloadUri)
    WebClient wc = new WebClient();
    wc.DownloadStringCompleted += ParseAndAddStyles;

This is just a pretty standard way of downloading a file.  It starts to get interesting when we process the downloaded XAML file (exception-handling code elided for clarity):

private void ParseAndAddStyles(object sender, DownloadStringCompletedEventArgs e)
    if (e.Error == null)
        var loaded = (ResourceDictionary)XamlReader.Load(e.Result);

private void MergeResources(ResourceDictionary resourceDictionary)
    foreach (ResourceDictionary dictionary in Application.Current.Resources.MergedDictionaries)
        if (dictionary.Source.OriginalString == "CustomizableResources.xaml")

This code parses the XAML into a ResourceDictionary, and then replaces the CustomizableResources dictionary that has been compiled into the XAP file with the one downloaded.

As you can imagine, there are a large number of failure cases which need to be considered in real-life (e.g. the web server gives a 404 or other error, the downloaded XAML fails parsing, or isn’t a ResourceDictionary, etc, etc) but this code is at the heart of our solution to the requirement.

July 28 2011
Newer Posts Older Posts