Scrum/How-to for Product owners
This page will shortly provide a basic guide to Scrum for those in the role of the Product owner.
Advantages of Scrum
Scrum provides a strong layer of abstraction between you and the team's work: The Sprint. It creates clear deliverables and review cycles and maintains daily transparency. This gives you a clear perspective on what is happening and what you are receiving when. You can set clear priorities and by having these you can more easily project the future.
New work request coming in? Just put it in your backlog and you can see what priority it needs to have, what things are going to be delayed by it, when your team could roughly achieve if it the plans don't change again etc.
By working iteratively you also don't need to know the entire requirements and all details for a project upfront. Schedule the first steps and when you see the deliverables in action decide how you want to continue.
Disadvantages of Scrum
The transparency of Scrum means you must break your work down into clear, concise stories that set simple requirements and are self-contained. This will often raise a lot of questions.
Transparency also means you have to do your homework:
Deciding whether story A or story B is more important often seems to be a big challenge. A common answer is "we need both". Sure, but not at the same time. This will put you into difficult situations sometimes.
Scrum also means you have to be in close contact with your external stakeholders so all important things are on your backlog.
How to handle new ideas and manage input
New ideas can come from yourself, from the team or from external stakeholders. Ask them to add their stuff at the end of the product backlog in the "Unscheduled backlog" section. Then you can prioritize the items and move them to the right place in the backlog. Nobody else is allowed to do this.
Make sure all stakeholders know that their input needs to be on your Product backlog in order to get executed. If someone rushes in and tells you he needs something right now, it most likely means he hasn't done his homework and is asking you to mess up your plans to cover up his fault.
How to prioritize
For each two items on the backlog you should be able to say which is the more important one. No two things can ever have the same priority and you cannot combine items to achieve this - that would be fooling yourself.
If one item is a prerequisite for another, it must have a higher priority.
When the team has identified weak areas in the code, you should prioritize their cleanup tasks higher than the tasks that will be building on the affected code.
How to break down items
Breaking down items is one of the most difficult tasks when coming from a classical waterfall planning. Look at them from the value angle. Not what steps need to be taken but what value do you need provided? Often this value can be split into increments. E.g. you may not necessarily need a whole Office suite at once but being able to write letters in plain text would be good start, then saving and printing would be next steps.
Never even think about separating documentation, development and testing. For each increment of work they belong together. Done is done.
How to think of acceptance criteria
What does the product need to fulfill in order for you to be satisfied? Write these acceptance criteria from a user perspective and leave room for the team's creativity. They may find another way to reach your goals than the one you had in mind - why obstruct them?
So tell the team what is the checklist of value that the result must deliver, not what parts should deliver it.
In case of emergency
There can be situations when your plans change drastically and the existing sprint plan becomes obsolete. E.g. a big problem has been found and fixing it cannot wait. Or the tasks that were supposed to be done in the current sprint are not needed anymore.
In such cases you as the product owner have the right to push the big red button: Abort the sprint. You can at any time call the abortion of an ongoing sprint. This means you will stop where you are and right after collecting a final status begin planning a new one.
Aborting sprints is wasteful: You will lose time planning again and communicating the sudden change to your stakeholders, you will disrupt the work rhythm of your team. In the rush, lessons that could have been learned will likely be overlooked.
Consider these losses carefully before deciding to pull this card. If a sprint is almost over it may be simpler to just rearrange your backlog quietly and apply your changes with the start of a new sprint.
Your role in a Review meeting
In the review meeting it's time for you to review what the team has done. Does it meet your Scrum/Acceptance criteria? Is it complete? Has the needed documentation and testing been take care of?
Sometimes you will find a task has been done as per your requirements, but at this point you realize you would have liked something different or more. So remember to add followup-tasks to your product backlog.
When you have reviewed all items, give the team feedbac: How happy were you with their performance? How many of the planned Story points have they successfully delivered?
Your role in a sprint planning meeting
In the sprint planning meeting you only play a role in part 1:
- Agree the schedule with the team
- Present the near part of the Product backlog (so the things you'd like to schedule now or soon) to the team and answer their questions
- If additional items were identified, add them now
- Have the team estimate this near part of the backlog in Story points
- If the team identifies a task that they think is too big (estimate 89 points) think and discuss on the spot about whether it could be split
- Ask the team which of the tasks (starting from the top) they want to be accepting into the new sprint
In part 2 of the meeting you can attend as a chicken if you want.
Your role in a daily scrum meeting
In the daily scrum meeting you are a chicken. It helps you to stay informed about what is going on, but you are not allowed to talk. Only if invited to, or if the team has time for you after finishing the regular Daily scrum, you can ask your questions.