What does it mean for a PBI to be committed while in the backlog in MSF Scrum 2.2?

Question

In attempting to understand what I'm seeing in TFS 2012 Web Access under WORK | backlog | Product Backlog, I used the "Create Backlog Query" button and then opened up the new query in the edit to see how it works. I noticed that it displays PBIs that fit two descriptions:

• PBIs anywhere under the root iteration (the backlog) in New/Approved state.
• PBIs in the backlog (the root iteration) in New/Approved/Committed state.

Why would a PBI fit this second description? Why would a PBI ever be committed in the backlog? Is it maybe some way of maintaining theme- or epic-level PBIs after refinement, and setting them to committed when their user-story-level children are committed to real sprints? Is it maybe just a means to compensate for shoddy bookkeeping where incomplete PBIs are kicked to the backlog but without reverting their states back to Approved? Maybe some other reason?

Answer 1

New - These are PBIs that someone has added to the product backlog and have not been reviewed by the product owner and have not been agreed to build.

Approved - These are PBIs that the product owner has agreed with, edited and made sure they are understandable for the team. Once approved they are ready for the team to pick up in sprint planning.

Committed - A Scrum team has discussed the PBI in sprint planning, created some tasks and agreed to do build the PBI in the current sprint.

Done - In sprint review, the product owner inspects the work the team has done and if he/she agrees it meets the requirements and quality standards, then the item is moved to done.

Answer 2

You're right! From a SCRUM perspective it doesn't make sense to list a Committed PBI in the backlog. The team has either committed the PBI to a sprint or they haven't.

Interestingly - the term Committed is not mentioned in the SCRUM Guide for Sprint Planning or Sprint Backlog.

My guess - Microsoft used the term Committed to describe the Development Team's ownership of a PBI when moved from the Product Backlog into a Sprint, but didn't want to enforce to the rule through validation or automatically changing PBI status.

If your looking for a more authoritative source - there is state diagram article on MSDN which describes the available status points without refereeing to Sprints.