Thursday, September 24, 2009

Scrum Master Role with Product Backlog

I've had a couple of intense discussions the last couple of days regarding the Scrum Master's role in managing the Product Backlog. During a Sprint Planning session, it was discovered that the backlog did not contain enough work for the development team for a 2 week sprint. During the planning session with the development team, a discussion started on what role the Scrum Master should take in ensuring that the Product Backlog was always detailed enough to provide enough work to fill a sprint. My stance was that the backlog is owned by the Product Owner and the Scrum Master should not have to spend time reviewing the backlog prior to the Sprint Planning in order to ensure it was ready or could become ready during the session. The planning session is time for the team to discuss the backlog and ask questions in order to gain enough details to provide an estimate and potentially accept the work for a Sprint. If the backlog is not ready and/or the Product Owner doesn't have the information the team needs during the planning session, then the team should not proceed. Some view this as the responsibility of the Scrum Master to remove the "impediment" of an inadequate backlog prior to holding the planning session. I disagree and would appreciate your thoughts on the subject.
Posted by at
Labels: , ,

1 comment:

  1. Scott DuncanSeptember 25, 2009 at 12:04 PM

    I believe having an inadequate Backlog prepared for the planning session is something the ScrumMaster should care about.

    For an inexperienced team, dealing with this can be disruptive by throwing off their velocity, their rhythm. That's a situation the ScrumMaster should want to avoid.

    For an experienced team, it would not be as bad. Some teams have a tech backlog they can use to fill in where customer backlog items might allow that to be done. So the team could just formally fill the iteration with such items right at the outset.

    But, in any event, the ScrumMaster needs to meet with the PO to see to it that this situation does not persist. It is important to know why such a situation has occurred and to discuss how to prevent it in the future.

    The team and ScrumMaster should not take a "tough if you can't keep us busy" attitude.

    ReplyDelete

Subscribe to: Post Comments (Atom)