Welcome to EMC Consulting Blogs Sign in | Join | Help

Simon Bennett's Blog

Descoping work in Scrum for Team System Version 3.0

It’s always been possible to descope work in the Scrum for Team System template. But the method employed in Version 2.2 whilst functional, was quite fiddly, overly manual and not very “Scrummy”.

When building 3.0 we took the opportunity to revamp the way in which it worked and better utilise the power of the Event Service (something you can see throughout the template).

Deliberately descoping work mid-Sprint is a very useful practice for Scrum Teams, especially when they first start out on a project, so we felt it was important to make this feel easier and more natural to do.

The headline change is that you now descope Product Backlog Items (PBI) rather than defer individual Sprint Tasks as was previously the case. The second major change is that we’ve made it much easier to rescope work.

Descoping PBI’s is a more natural flow for a Scrum team – and more accurately models what should be happening at a project level. Remember that good Scrum teams will always descope work well ahead of Sprint Review, descoping (or rather dropping) work the day before Sprint Review is missing the point entirely.

So this is how it works:

Some time during the Sprint, the Scrum Team comes to the realisation that they’re “not going to make it” – there could be any number of reasons for this, one or more team members could have fallen ill (Bill for example), some of the estimates may have turned out to be severely incorrect or there may simply be some other impediment which cannot be resolved in time to allow the team to deliver on its previously committed Sprint goal.

The fact that “we’re not going to make it” should be clear from looking at the Sprint Burn Down chart (remember that the Sprint Burn down is for the team to use to track their own progress). Once the team discovers this fact, the next step is to inform the Product Owner (if they don’t already know) – and to have a discussion about what can be delivered in this Sprint. (Given what we now know)

The discussion of what can be delivered this Sprint will however almost invariably lead to a discovery of previously committed-to work that can no longer be delivered this Sprint. This is the work that we need to descope. So how do we do it?

Ideally you’ve been limiting your Work In Progress and working in priority order down your Sprint Backlog. If this is the case then it’s more than likely that the stuff the PO agrees that you no longer need deliver this Sprint (because it’s a lower priority), hasn’t been started (because you’ve been limiting WIP) – see how all this stuff fits together?

In this case, fire up Visual Studio 2010 and bask in its glory; then go to Team Explorer and find the Product Backlog Item(s) that you are wanting to descope and set their status from “Not Started” to “Descoped” – and then save them straight away.

Saving the work item will kick off our Event Service which will then set the status of all the linked and “Not Started” Sprint Backlog Tasks to “Descoped” as well.

Sprint Tasks that are set to “descoped” don’t count against your work remaining for the sprint – and thus allow you to see whether your descoping effort is going to mean you’ll be able to deliver on your new commitment. Those PBI’s and SBT’s are still attached to the same point in your Planning Scope, but they no longer count against work remaining in any of the reports.

But what if Bill gets better and then puts in some overtime?

So this is one of the reasons we leave the Iteration Path / Planning Scope alone. You want to keep that PBI in your Sprint Backlog, because it represents part of your original commitment. That’s important data to take into your Sprint Review and Retrospective to help you improve your estimation and relationship with the business. The point of descoping PBI’s is not to hide the work. It’s for no other reason than to mark the PBI as something that’s not part of the “new commitment” (but was part of the old one) – and more importantly, by association to take the planned Sprint Tasks out of the work remaining in the burn down.

Never forget that the goal of Scrum is transparency, it’s not about making events look bad or good, it’s about representing them as they truly are.


If it all starts to “come together again” and you realise as a team that you “descoped prematurely” – then there is no problem. You can simply rescope the PBI by changing its status from “Descoped” to “Not Started” and once again our friend the Event Service will do the honours for the linked Sprint Tasks, setting them all back to “Not Started” as well. Make sure however, that you actually finish all the PBI’s that were not descoped first. All the way to Done.

Don’t rescope PBI’s because you “feel” that you might be able to do them after all. Finish the other PBI’s first, then rescope (and then send me a postcard)

This is basically the same procedure that you’d follow in the far more likely case that the PBI stays out of scope for the entire sprint. In this case highlight at Sprint Review the items committed to, and those completed and briefly and objectively discuss the descope moment and the reasons for it. It’s likely that you’ll want to spend a good chunk of your Retrospective on the reasons behind why descoping was necessary.

Our recommendation is to leave the Planning Scope of the PBI alone until after Sprint Review. After Sprint Review, push the PBI “up” the Planning Scope, typically to the Work Stream or Release Level, and then set it back to “Not Started”, effectively putting it back in the Backlog for reprioritisation and scheduling by the Product Owner (the fact that it was once planned and then descoped is stored in the history). If you’re the ScrumMaster, resist the temptation to simply roll it over to the next Sprint. That’s not your call.

When you do allocate it back down to Team in the Planning Scope; all the previously planned Sprint Backlog Tasks will come with it, again thanks to our friend the Event Service.

If you forget to rescope PBI’s they can sometime get lost – which is why we have added a “Descoped PBI’s” WIQL query, so that you can keep your project in order and not lose work “through the cracks”. Check it on occasion.

A final note on half started PBI’s

In some cases you’ll need to descope a PBI that you’ve already started. In this case you’ll likely have a “spread” of Sprint Tasks, some of which are “Not Started”, some of which are “In Progress” and some of which are “Done”.

Obviously the Tasks which are “Done” – don’t really matter. We’ve done these and we can never get that time back. The Event Service simply leaves these tasks alone. Similar deal with the “Not Started” work. We’ve agree with our PO that we’re not going to deliver this PBI this Sprint, so the Event Service assumes that all these tasks will also be descoped and sets their status accordingly.

That leaves the “In Progress” work. The Event Service will just leave this alone; this means that these Tasks will stay “In Progress” even though the PBI itself has been descoped. This “In Progress” work will still count against your work remaining target in your Sprint Burn Down chart until you either finish the tasks, or descope each of them manually.

Remember however that when the PBI is rescoped, all the descoped tasks will go back to “Not Started” – regardless of what state they “came” from.

Published Friday, January 22, 2010 4:08 PM by Anonymous

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS



Peter Lindberg said:

I really like what you've done with the new template, I'm looking forward to introducing it to our teams when we start using 2010. Good job!

January 24, 2010 8:36 AM

Crispin Parker's Blog said:

This posts relates to the Scrum for Team System version 3 process template and Team Foundation Server

February 26, 2010 12:20 PM

Brian Shotola said:

Regarding "half started PBI’s", what do you recommend to move a PBI from Sprint 1 to Sprint 2 if it was not fully completed in Sprint 1?  If you just re-assign the PBI to Sprint 2, all of the completed hours will come along with it distorting both Sprint's actual worked hours.

Also, what would you do with a half started PBI if the Product Owner decides to deprioritize the PBI so that it will not be worked on in Sprint 2?  We'd want the PBI to go back on the Product Backlog for potential future prioritization, but we'd still want to leave the worked hours applied to the Sprint part of the PBI was implemented in.

May 26, 2010 10:38 PM

Anonymous said:

Hi Brian,

When you change the Iteration Path of a parent PBI, the completed hours are never moved forward - nor are the completed Sprint Tasks. This is true for both Version 2 and Version 3 of the template (precisely for the reason you have mentioned) - only undone SBT's are moved forward.

This same is true if you put the PBI back on the backlog by moving it to the release or workstream level (or in fact move the PBI several sprints forward).

The work done in the Sprint is left in the Sprint. Only undone work is carried forward.

So both of the scenarios you have mentioned are catered for and "do the right thing"

Kind Regards,


May 27, 2010 9:32 AM

Crispin Parker's Blog said:

A recent question in the Scrum for Team System Q & A site has highlighted that there is a lack of

December 10, 2010 6:00 PM

Leave a Comment

Powered by Community Server (Personal Edition), by Telligent Systems