One more article on SCRUM, Uff, and that is targeting the folks who are already practicing the Scrum. I guess readers of this article are not newbies to Scrum, if not experts. Consider a situation, where you are a strong Scrum Team lived and honor the Scrum Theory and Scrum Values yet constantly fail to deliver. As a result, wearing the cap of Product Owner of this team, one continuously feels the pressure of being a failure. Let’s take an opportunity to self retrospect as Product Owner, and try to find out if is it ‘me’, who proved to be an ‘impediment’ for team’s productivity.
Are you dictating the team
Being the Product Owner you are responsible for maximizing the value of product and team. Big question is how you are trying to accomplish this. Scrum Teams are self organised, who themselves choose how best to accomplish their work, rather than being directed or dictated. As product owner you have full right to put your thoughts before your team but should limit yourself from being a ‘Task Master’. Scrum clearly defines the responsibilities of each role, and team is supposed to ‘Respect’ others’ domain. Activities like Story Sizing and Sprint Capacity Planning should be driven by the development team, and you have to honor teams’ decision for this.
Are your stories including ‘How’ rather ‘What’
One of the biggest mistakes, product owner does while writing the story, is that he mentions ‘How’ to carry out the development work. Again, scrum team is ‘Self Organised and Cross Functional’, where design and development of the task is sole responsibility of the development team. Your thoughts on ‘How’ may mislead their approach of design and development. As product owner you have to cautiously write ‘What’ you want as outcome but not ‘How’.
Your stories : Simple or Simpler
Fundamentally, it is said that user story should be simple. Which is absolutely correct with one exception that it should not be ‘very simple’. Revisit your story and if possible, try to get this previewed by fellow members. Is your simple content enough for explaining the task ? Have you mentioned business critical issues addressing, “If this then That” or “If Not this than that”? Does your story need some pictorial explanation, may be a flow chart, or other UML depiction? Can we include UI mock ups for better understanding? Intent of the subject is that, making your story simple is necessary but not on the cost of the team effort.
Ambiguity in acceptance criteria
Very common and frequent issue faced by the development team, “What exactly do I need to do with this”. Every human has his own style of writing and most of the time one thinks that he has written a ‘complete’ statement. Your team member, who is a different individual may interpret the same statement differently. As Product Owner, are you giving extra room to your team for what you have mentioned as Acceptance Criteria? While reviewing the development work, you might be shocked to see the difference between what you wanted vs what has been developed.
Are you reviewing the work done during sprint review meetings
This is one of the most common mistakes done by the ‘busy’ product owners. Scrum advocates team coordination, where development team is supposed to design the work as per mentioned acceptance criteria. Continuous interaction among team members, including product owner himself is very important. With close team interaction, development team can approach product owner to pre-review under development work and to take feed back during sprint itself. Early detection of deviation due to any reason, may get rectified well in time. Late detection of ‘deviation’ may cost commitment of ‘Shippable Product’. Hence a mechanism may be designed to review the development work carried out by the team on regular intervals, or as team suggests.
All in all, the entire Scrum team is responsible for its success or failure, but every member of the team must deliver his best. And one should not wait for the retrospective meetings to retrospect ‘his’ own efforts. 🙂