16

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?

bwerks
  • 8,651
  • 14
  • 68
  • 100

2 Answers2

78

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.

Brett Maytom PST
  • 1,193
  • 7
  • 6
  • 1
    Sorry, this doesn't really address the question. – bwerks Jul 03 '13 at 07:17
  • 6
    Ok, I will spell it out to you. You have a product backlog with a list of requirements for the entire product. These requirements may go be assigned to different teams. Anyone may add a product backlog item to the product backlog. Thus it is new. If the PO likes the idea, he/she can approve it. At sprint planning time a team pulls in the product backlog item into their sprint backlog, and mark it as Committed; that is a team is working on the PBI in the current sprint. Once the PO is happy the team has delivered the PBI, the PO marks it as done – Brett Maytom PST Jul 06 '13 at 03:09
  • 1
    Your first thus means work that has not started. The second means incomplete work including work that has not started – Brett Maytom PST Jul 06 '13 at 03:13
  • 1
    I think the main point here is that the committed pbi exists both in the backlog and the sprint at the same time. So any committed pbi is actually in the backlog, too. So even though it says "Move to iteration" it does not move from the backlog - it stays there until it's marked as Done. – Reimund Jul 24 '15 at 14:30
  • I agree with the OP. I think that Approved vs Committed should be automatic. If a feature is added to a sprint, its stats should be automatically set to Committed, and if it's removed from a sprint, it should automatically go back to "Approved". It's a bit cumbersome to have to drag it twice. – JoeMjr2 Oct 01 '16 at 17:50
8

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.

enter image description here

Kye
  • 5,919
  • 10
  • 49
  • 84
  • Sounds to me like Microsoft included a Committed status to satisfy a database requirement. Of course, I could be wrong. – Rod Nov 28 '22 at 21:58