Timeboxing of Product Backlog Items

In order not to affect the normal development time, this kind of work usually be time-boxed.

For example, during Product Backlog refinement, a Development Team may decide to create a spike for certain features or architect.  This spike will be added to the Product Backlog and be pulled to the Sprint Backlog of the current Sprint or next Sprint. Refinement spike usually has two characteristics.  It always has clear objectives and it is timeboxed. Start with the timebox and after that decide if you need more time or or give up.

Some teams may also add a special item to handle urgent or temporary tasks to provide a flexible time for the development team. This item is also timeboxed.

In many organizations, it is not possible for the Scrum team to perform only the development of new features. There are usually some unexpected chores to deal with. If you can't avoid it, then face it bravely.

But at least to do:

1. Transparency

2. Timeboxed  - Do not affect the normal development work.

I've recently started at a software company where it's common to timebox certain Product Backlog Items, such as mysterious bugs, refinement spikes, or other tasks (not code changes) that need to be completed.

How clearly are the expected outcomes articulated for this sort of timeboxed work?

How clearly are the expected outcomes articulated for this sort of timeboxed work?

I believe the expected outcomes are generally clear to the team, but the uncertainty lies around finding the solution. This can be particularly true of bugs, where the majority of work is often spent investigating the cause.

In the case of some tasks, the expected outcome and planned approach are clear, but all tasks are timeboxed due to a convention of the team. 

Timeboxing in the manner you describe can be used to control risk, because any potential losses are cut. For example, a gnarly bug may eventually take 2 days to resolve, but the loss at any given point can be constrained to a timebox of much shorter length.

However, there can be a lack of rigor concerning outcomes, because the defect is not necessarily resolved by the end of a timebox, and so transparency over value and flow can be reduced.

Generally speaking, it is best to try and constrain the use of such timeboxes to spikes, with the express outcome of being able to estimate or size an associated piece of work. This approach to de-risking is essentially a refinement activity, whereby uncertainties that would otherwise be introduced into Sprint Planning are mitigated.

Thanks for the explanation and advice, Ian. Very helpful!

Simon, spikes can be useful and a time box is a good way recognising and limiting the scope of the investigation.  I agree with Ian that you need to very clear about the outcome of spike and knowing when you've finished.  

However, these sorts of spikes can be used as an excuse for inadequate backlog refinement. So worth keeping an eye on. Routine refinement should be absorbed by the team.

The argument of pointing bugs is interesting.  My own preference is 'no' for the following reasons.  1) They are notoriously difficult to estimate.  2) It can hide quality issues as your velocity will remain stable where you really want see a dip if you are spending time fixing stuff you've delivered. 3) Bugs shouldn't be 'normal'.  Of course, they will happen but every one should be a an opportunity to look at Dev and QA practices to see why it slipped through.  Time-boxing a bug?  Not sure. You may well see the time-box expire and be no further forward.

Does not sound out of the ordinary. How does it affect your sprint delivery?

Lots of good information here.  I'll add one small piece. I am often asked by teams if they should point spikes, and my question back is 'what is the purpose?'.  A spike is supposed to be time-boxed to an agreed upon time limit, therefore you already have your estimate.  Why waste any more time pointing it?  

I tend to lean towards not pointing bugs either.  It may help to gather empirical data around how many bugs are being added to the Product Backlog, and use that as one of the inputs into Sprint Planning.

However, these sorts of spikes can be used as an excuse for inadequate backlog refinement.

To be clear, my advice is to use these spikes as part of backlog refinement. Hence they are time-boxed but not pointed, the objective of the investigation being to create a sufficiently detailed, estimated and “ready” piece of work.

All the teams I've worked with have used timeboxed spikes for backlog refinement purposes. My observation is that that approach works best when it is restricted to the following (or similar) cases:

1.) Selection of Technology: When it is clear that new technology must be introduced into the software development in order to achieve the desired outcome, but there are several options available. In this case, the team might use the timebox to evaluate the options in paralell, then report back to discuss the pros and cons of each option.

2.) New Technology: New technology must be introduced into the software development in order to achieve the desired outcome and it is clear what technology will be used. Hoewever, the team has no experience with it and is therefore unable to provide an estimate that they are comfortable with. In this case, the team might want to experiment with the technology to arrive at a better estimate.

3.) Prototyping: When, in order to arrive at a clear understanding and/or estimate of a PBI, it is necessar to do some exploratory prototyping, a timebox works well to ensure the prototype is a prototype and not a full implementation.

To be clear, my advice is to use these spikes as part of backlog refinement. Hence they are time-boxed but not pointed, the objective of the investigation being to create a sufficiently detailed, estimated and “ready” piece of work.

Ian, would you put these items on the sprint backlog, ie be part of the sprint forecast?

Ian, would you put these items on the sprint backlog, ie be part of the sprint forecast?

They would not constitute part of the Sprint forecast (i.e. the forecast of work to meet the Sprint Goal). Therefore if they *were* to be included on the Sprint Backlog, it should not be for that reason.

Teams are at liberty to include work on their Sprint Backlog which is not necessarily aligned to the Goal. A case in point might be actions from a Sprint Retrospective, although arguably even then the actions which are selected ought to support the Goal in order to be as timely as possible.

In the case of investigative spikes, however, the rationale for including them on a Sprint Backlog would be dubious. Scrum allows up to 10% of the time during a Sprint to be reserved for refinement activities. I’d say that any spike which is effectively for refinement purposes ought therefore to be included in that budget and handled in that spirit.

Agreed, Ian.  When sprint backlogs become dominated by investigative spikes it can be a sign of not handling refinement adequately in that spirit.

I have a different take on that, actually. Because a Spike is a work item which is to be completed in the sprint. Seeing as the Sprint Backlog should provide transparency over the work that is to be done during the aprint, I would include the spikes in the sprint backlog simply for increased transparency.

I've seen it handled both ways. Both work. So this is more of a preference of mine ;-)

Just for the sake of coordinating items of work, timing, etc. I've found Development Teams that include required extra-curricular on a Sprint Backlog to be useful to them.  So long as they retain the focus of the Sprint Goal.