You are here

Dealing with 'Late arriving' User Stories


An issue that often arises during the sprint retrospective (the most important Scrum event), for new teams is the fact that not enough is known about very new high priority stories to be able to estimate them. This leads to wildly varying estimations, arguments about how or what should be done, committed work not being completed during the iteration and a whole host more problems. It also make the negotiation between the Product owner and the team very 'interesting' during the planning session.

Reasons for these late arrivals could be:

  • They are a new requirement added at the last minute under pressure from the customer
  • The Story has been around for a while a low down in the backlog, but the priority has recently changed
  • Remedial action is required somewhere (A bug needs fixing urgently)
  • ..... the list goes on.

This is especially a problem at the start of a project before things have settled down, and even worse when the technology or environment is complex or new to the team. You can not realistically expect the team to commit to work that they do not understand enough to address. (The Stories are simply not yet ready to play)

A quick look at 'The Scrum Guide' tells us that the Product Owner should, amongst other things, be clearly expressing Product Backlog items in a visible and transparent manner. Surely this means it is up to them to get their act together? Party yes, but we work as a team, we succeed as a team, we fail as a team, we FIX as a team.

So how do we fix it then we have been doing all the required backlog grooming (At least 10%) but we keep getting hit with the problem?

The root of the problem is that there needs to be a little more effort on the product road-map and planning, rather than simply having a last minute reactive approach.

One part of solution is to have a formal grooming session around the middle of each week of the iteration (All it needs is an hour a week). This way the Product owner can quickly and easily update the team on changing priorities and requirements. The team has some time to extract the real need and think about how it can be implemented and integrated with the rest of the product. More knowledge is gained (from both sides) and any trade offs can be discussed and agreed. If need be the story can be split. All stories near the top of the backlog are in a 'Ready to Play' state. Sure this leaves 2 or 3 days for the unexpected to happen but with time and practice the impact can be minimised and the team will cope.

This leads to the second part of the solution. Here we need a little more cooperation from the Product Owner, They need to realise that this kind of 'Late in the day' disruption can really hurt the productivity of the team and the smoother the flow of work, the better product they will receive and the faster it will be produced'. It also means that there needs to be a little more push-back on 'absolutely highest priority' late arrivals in the product backlog. A little more effort with the customer and a long hard look at the product backlog, its epics, their breakdown and priority should go a long way.

Using the free scrum tool available in the resource section of this site may help with this as the backlog and epics can be ordered independently.