Online Discussion on Scrum Requirements Basics

The ScrumDevelopment list boasts an embarrassment of experience among its active members.  Despite this (or because of it?) newbies are welcomed and often sow the seeds of very interesting discussions.  This month, two brief questions have started long threads relating to customers and requirements.

Graeme asked for advice on value prioritization of the Product Backlog, saying: "I have seen a number of examples of prioritising the product backlog according to business value, including:"

• Very High, High, Medium or Low
• Moscow
• A value between 1 and 10
• Allocate 1,000 arbitrary units of value...
  

Responses from veterans Mike Cohn, Ron Jeffries, Brad Appleton and numerous Certified Scrum Trainers, among others, explain the techniques they have used and seem to agree on a few things: it needn't be complicated to be effective, and don't think you'll do it once and be done with it - priorities shift continuously.  They particularly look at the problems with the "always 1000 units" prioritization scheme used in the Scrum for Team System add-in for Microsoft Visual Studio Team System, developed by Conchango ScrumMasters in conjunction with Scrum creator Ken Schwaber. Visit the list to read about Mike Cohn's "prioritization poker", a variant on the "planning poker" he wrote about in  Agile Estimating and Planning.

In a second question about the Product Owner, the person woh "owns" the Product Backlog, Satish asked: "For a small development team, can we have the Product Owner also acting as Scrum Master?"  It's a common question - the overhead of having both ScrumMaster and Product Owner can seems heavy for a small team... but the dichotomy exists in the methodology for a reason.  Despite the odd "I've done it" post,  senior coaches like Mike Vizdos urge that teams keep the roles separate to make accountabilities clear for the team as they transition to Agile.  And Tom Perry notes " It's remarkably easy to do, especially when the person who 'should' be the PO is a weak or non-existent presence," but he also notes: "Been there done that. Ouch!"  Indeed, many would agree that this is a classic "bad smell" to be guarded against.

Lowell Lindstrom chimes in with some wisdom:

"Scrum defines the ScrumMaster, Product Owner, and Team as three distinct roles best performed by separate participants. However, it is often more insightful not to view this as a can/can't question, but rather a strengths/weaknesses exercise."

And a third requirements-related topic, on "QA's role in a SCRUM/Agile process", has had members discussing who gets to  "done" - Tester? BA? Product Owner?  This question has so far failed to resolve one way or the other - but there is still time to participate.  It is an important question - is there any point in involving the customer in requirements, if in the end some other party gets to define what was "really" required?