Scrum basics: The daily standup meeting

Easy to start, difficult to masterSometimes referred to as a “daily sprint meeting”, this is a short meeting that happens once a day.  At this meeting, each member of the team should answer three questions:

  1. What did they do yesterday?
  2. What do they plan to do today?
  3. What issues are blocking or slowing down progress on their tasks?

The purpose of the meeting is for the team to co-ordinate their activities, to avoid duplication of effort and to ensure that their output is not in conflict.  The meeting should typically last 15 minutes or less when everyone is in the same room.  Somehow when people attend by phone or Skype then the standup meeting normally takes 20-30 minutes.

When the daily standup is working well for the team, it will often spark off a number of side conversations.  These are typically relevant to just a few members of the team.  Best practice is for these discussions to take place immediately after standup.  So in general, team members should leave the daily standup with a list of people to talk to about specific matters.

IMO the daily standup meeting is the best indicator of how well the team works together. In a high-functioning team the members collaborate actively and are concerned with both how their works impacts others as well as how the works of others impacts their own work. This means that the members of a high-functioning team are (a)actively trying to give useful updates; and (b) are actively listening to assess the impact of other people’s updates.

When to hold the meeting

Ideally the meeting should be held at the start of the day.  This provides team members with a good way to plan their day and formulate their list of activities.

However, there are sometimes a number of circumstances that mean this is not possible.  For instance, a team may be distributed over a number of timezones.  In this case, it is more important to pick a time that allows everyone to attend.

People who miss the meeting

A great habit to establish on the team is to ask people to send an email to everyone if they can’t attend in person.  This highlights to the team that the important aspect of the standup meeting is actually about communication.

Things that can go wrong

There are lots and lots of ways in which the daily standup meeting can wrong.  Here are some of the ones that we at #Fellows have seen:

  • Standup meetings can last too long – we’ve heard times of an hour!  This is often caused by people holding topic-related discussions during the meeting and not afterwards.  This can be addressed by having a team agreement that allows discussions to be parked until after the meeting.  Over-long standup meetings can also be a sign that the team is too big.
  • Some individual can give overly long updates – some people are not naturally concise and it can sometimes appear that they just like to talk.  This situation is best dealt with by taking the people aside and having a one-to-one chat with them, and explaining the difficulties that they are causing for the team.
  • Standup meetings can be too short – although those suffering from over-long standup meetings may find this incredible to believe, an overly short meeting is not good either.  This indicates that team members are too focussed on getting out of the meeting and don’t give enough detail in their updates.
  • Updates of planned activity can be vague – the standup meeting actually requires that team members have a reasonable idea of what they will do over the course of the day.  Some people resist this level of forward planning and instead say “… and then I’ll pick up the next task”.  This is not acceptable for an update and it needs to be clear to people why not.
  • Updates of completed activity can be vague – if team members are unable to understand someone’s update then it’s a signal that there may be different ideas about the actual work being done.  This should be resolved by dicussion outside of the standup meeting.
  • Updates cannot be reconciled to the sprint backlog – this means that the tasks on the sprint backlog no longer bear much resemblance to reality.  They team members should scrap them and draft some new tasks that more accurately describe the actual work.
  • People talk about activity rather than achievements – if team members are regularly saying “yesterday I worked on X and I will continue with it today” then it’s a signal that the planned tasks are too big.  If tasks are sized so that they are achievable within a day, then every team member should be able to give an update of a completed task every day.
  • People switch off when they are not talking – if team members are not actively listening to other people’s updates then it shows that they regard the updates as unimportant.  Most people feel this way until they get burned once or twice by not being aware of current activity.
  • Managers and other stakeholders hijack the meeting – while stakeholders are welcome to listen in to the standup meeting, the meeting is held by the team and for the team.  Only those contributing to the sprint goals should be taking up airtime.

Distributed teams

When a team is split over multiple physical locations, then there are a couple of options available:

  1. Everyone connects to a conference call / Skype call and gives updates
  2. The team can be divided into sub-teams which have their own standup meeting

This second option is really only feasible if there are a couple of locations with a substantial number of people.  It will not work if there are a larger number of locations with just one or two people at each.  To handle standup meetings with sub-teams, use the Scrum of Scrums approach outlined below.

Scrum of Scrums

There can be a couple of factors that push the project team to split into sub-teams.  Geographical dispersion may be one (as discussed above), and sheer numbers of people may be another.  Standup meetings quickly become ineffective when there are more than about 12 people involved.

Each sub-team should hold their own standup meeting, as described above.  Following on from that, one representative from each sub-team meets together for a scrum of scrums.  The format is similar to the standup meeting, except that the people are speaking on behalf of their sub-team rather than on their own behalf.

The scrum of scrums should be open to anyone who wishes to attend, but their needs to be a single designated member of each sub-team who will be talking.

Often it’s useful for the sub-team representative to report back (informally) to the other members.  This allows them to highlight the activities of the other sub-teams and deliver solutions to blocking issues that have been raised.

September 12 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
Newer Posts Older Posts