Role of PMs in scrum process
We are just about to finish the 5th sprint. I blogged earlier about agile development at CRM team, but at the time I had little clue on how Program Managers(PMs) can add value to the new process. 5 sprints later, I think we know more about the role of PMs. Let’s just say that the postmortem of the first few sprints (you must do a postmortem after each sprint) weren’t very rosy for PMs, whereas the postmortem of the last sprint was much more positive on effectiveness of the PM role. So I learned a few lessons, some of which are: 1) writing PM specs on-the-fly is a myth! especially if the spec is deeply technical and has rather complex scenarios. I don’t mind thinking on my feet and writing a small spec for a small feature but I will not write a spec on a fundamental and critical feature set without sitting back and taking as much time as it is reasonably needed to do the proper customer/technology research and design a software that is built to last for at least for 2-3 versions. Write the specs, develop the designs and close on critical issues before the sprint start. It is fine to enter the sprint with a few non-critical unresolved details. In such case, ensure adequate work items and time is allocated for closing out and resolving those details 2) Think customer scenarios all the time especially when putting together the sprint product backlog or cutting items from it. Your product backlog should be an absolute ordered list of customers scenarios and not features. This will reduce the risk of cutting a feature that directly or indirectly break a customer scenario. In our team PMs are product owners and dev and test leads are scrum masters so what I am writing here is just from the product owner perspective.