Comments on: Maintain One List of Work http://www.gettingagile.com/2009/06/12/maintain-one-list-of-work/ with Sterling Barton Fri, 19 Feb 2010 16:23:50 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Chris Sterling http://www.gettingagile.com/2009/06/12/maintain-one-list-of-work/comment-page-1/#comment-144 Chris Sterling Fri, 28 Aug 2009 02:35:01 +0000 http://chrissterling.gettingagile.com/?p=281#comment-144 Yes, we do. There are a couple of things that are important. If the bug is existing, we might bundle it into a group of bugs and then fix as many as possible within a defined story point budget. Or we could just not give any points which allows your velocity to just be what it is while catching up on fixing defects. In most teams I work with nowadays, with smaller codebases and less technical debt, they do not create any significant bug count at all and so fixing defects just doesn't happen often enough to get them in the PB. Those are highly experienced Scrum with XP technical practices teams and it has taken time for them to get like this. The idea with maintaining one list of work is to make it difficult so that the threshold of pain is low and people will do something to fix the situation or it causes more pain. Yes, we do. There are a couple of things that are important. If the bug is existing, we might bundle it into a group of bugs and then fix as many as possible within a defined story point budget. Or we could just not give any points which allows your velocity to just be what it is while catching up on fixing defects. In most teams I work with nowadays, with smaller codebases and less technical debt, they do not create any significant bug count at all and so fixing defects just doesn’t happen often enough to get them in the PB. Those are highly experienced Scrum with XP technical practices teams and it has taken time for them to get like this. The idea with maintaining one list of work is to make it difficult so that the threshold of pain is low and people will do something to fix the situation or it causes more pain.

]]> By: Peter Martin http://www.gettingagile.com/2009/06/12/maintain-one-list-of-work/comment-page-1/#comment-143 Peter Martin Tue, 25 Aug 2009 00:01:15 +0000 http://chrissterling.gettingagile.com/?p=281#comment-143 We often find ourselves in the predicament you describe. Are you using points and velocity? The challenge we have when working from a single work queue is people expect to see points for defects, which always proves to be unreliable and skew the velocity. We often find ourselves in the predicament you describe. Are you using points and velocity? The challenge we have when working from a single work queue is people expect to see points for defects, which always proves to be unreliable and skew the velocity.

]]> By: Daily Links for Monday, June 15th, 2009 http://www.gettingagile.com/2009/06/12/maintain-one-list-of-work/comment-page-1/#comment-142 Daily Links for Monday, June 15th, 2009 Mon, 15 Jun 2009 11:57:24 +0000 http://chrissterling.gettingagile.com/?p=281#comment-142 [...] Chris Sterling’s Blog » Maintain One List of Work [...] [...] Chris Sterling’s Blog » Maintain One List of Work [...]

]]> By: Jayson Raymond http://www.gettingagile.com/2009/06/12/maintain-one-list-of-work/comment-page-1/#comment-141 Jayson Raymond Sat, 13 Jun 2009 18:44:48 +0000 http://chrissterling.gettingagile.com/?p=281#comment-141 Very good point. The transparency and singleness of purpose provided by consolidating to a single prioritized list of what needs to happen next can only help the Product Owner feel in control of how and where their budget is being spent - and I like how you strive to expose the hidden work that developers are often not appreciated for and which frustrates the owner. Some Product Owners may become frustrated that these additional entries in the backlog clutter the prioritization of features. In this case, perhaps encouraging them to publish a separate roadmap communicating the high-level, strategic directions/features currently being considered (but not committed to) may prove useful - AS LONG AS this is never confused as being the Backlog, the _tactical_ tasklist the owner has signed off on and which the development team is to take marching orders from. Very good point.

The transparency and singleness of purpose provided by consolidating to a single prioritized list of what needs to happen next can only help the Product Owner feel in control of how and where their budget is being spent – and I like how you strive to expose the hidden work that developers are often not appreciated for and which frustrates the owner.

Some Product Owners may become frustrated that these additional entries in the backlog clutter the prioritization of features. In this case, perhaps encouraging them to publish a separate roadmap communicating the high-level, strategic directions/features currently being considered (but not committed to) may prove useful – AS LONG AS this is never confused as being the Backlog, the _tactical_ tasklist the owner has signed off on and which the development team is to take marching orders from.

]]>