…continued from Part 1, What is a Product Owner?
As I strive to improve my role as Product Owner on our Scrum Team (“Agile”), I thought it useful to create this list of things that a Product Owner should do.
1. Create a Product Roadmap to articulate Product Strategy “as we know it”
I recently had a great email conversation with Kevin Donaldson, VP of Product Management at Balihoo. Kevin outlines his view of a Product Roadmap:
“I create a Product Roadmap to articulate Product Strategy as we
believe it to be right now – it maps market events, architecture,
features to a market map (who benefits). As you know it isn’t meant to
be a project plan – it’s a view of the world that we update each quarter
to help show our product strategy and vision of where we are heading (at
least based on our current knowledge of the market).”
I think this is a great summary from Kevin. The Product Roadmap can be used to guide other parts of the Product Owner’s job. This is something that should be internally public, so post it to your company’s wiki or intranet.
2. Host recurring Product Council meetings
The Product Council is made up of key Stakeholders from Sales, Customer Support, Marketing, Technology and Corporate Strategy. Use this meeting to provide updates to the group (usually consists of execs who won’t read your Release/Iteration notes), prioritize themes or epic features to prepare for your next release and ask/answer questions about the products you own. The Product Council helps steer you in the right direction. During this meeting, continually refer to the Product Roadmap you’ve created.
3. Have a good Release Planning meeting with the Team
One of the hardest parts of being a Product Owner is elaborating User Stories ahead of time so you can make decisions about what should go into a Release. The Release Planning meeting is hosted by your team’s ScrumMaster but you do most of the talking. The team asks you hard questions about specifics that haven’t occurred to you yet. You will be slightly embarrassed as you realize certain Stories are not well elaborated and you are not as prepared as you thought. Come out of this meeting with Plan Estimates for every Story inside your epics or themes. Usually we have 5 or so “Children” Stories for each “Parent” Story (we use Parent Stories to capture epics/themes). I have yet to see the team 100% committed to what we discuss during Release Planning. This meeting seems to be about helping me fully vet out everything and rough out a Release Plan.
4. Publish your Release Commitments internally
Create a blog post, etc that describes in English the stuff you plan on building in the upcoming release. Group things by Product or Function and make it a very easy read. Who does this feature apply to, give a one sentence “business intent” or “benefit”. Be careful how you write this because you are really “committing” to this and everyone will refer to this post in the future to gauge your success. I have had killer releases where everyone was cranking and we didn’t deliver on things in the Release Commitments, usually because the thing became irrelevant something before we began. Anyway, it still felt like we did something wrong during the Release because we had published that we would complete that thing.
5. Have a good Iteration Planning meeting with the Team
Iteration Planning happens every 2 weeks on Tues for our team and is taken very seriously, this didn’t used to be the case. Tues is great because it gives the team Mon to get loose ends wrapped up. As a Product Owner, you need to be ready to talk specifics about each User Story you have slated for the upcoming Iteration. Besides talking about the Story and what it will do, be able to answer 3 questions 1) Why are we doing this? 2) How will this be tested? and 3) What is the definition of done? I know many will argue that 2) testing is the responsibility of the QA lead however, I have noticed that the Product Owner’s understanding of how everything fits together directly relates to their understanding of how a new something should be tested. What other parts of the app is this new thing going to impact? How will users be using this new thing?
Never come to Iteration Planning with an Iteration overloaded with Stories. You need to understand your Team’s velocity so everyone on the team can be realistic about what will get done in the next 2 weeks. At the end of Iteration Planning, you should have a well tasked, well understood workload for the team.
6. Publish your Iteration Notes at the beginning and end of each Iteration
Export your list of Stories and Defects committed to during Iteration Planning and upload to your company wiki, etc. I have found this doesn’t need to be a detailed blog post, just a communication to the company so certain people who are waiting on specific items can scan the list, ask you questions, etc. At the end of each Iteration, create a blog post similar to your Release Commitments called Iteration Notes that summarizes in English what you accomplished, how it will be rolled out, who it benefited, etc. I have seen people print out the Iteration Notes I publish and keep them at their desk as they respond to support questions or talk with a new prospect.
7. Attend Daily Standup
In a lot of the Agile literature I’ve read it seems the Product Owner is expected to checkin at Standup from time to time but not be there everyday. The best Iterations our team has is when everyone is totally engaged and attends Standup everyday, including me the Product Owner. Standup gives me a feel of how things are progressing, helps me answer questions and make decisions about Stories on the spot to keep the team cruising along, and is a motivation for making sure my Tasks are getting marked complete (usually I have a few tasks during an Iteration).
8. Host the Iteration Demo
Every Wednesday our company has a “Lunch n Learn” in which pizza or burritos are brought in and we all sit in the conference room to have lunch together. Every 2 weeks I have an Iteration Demo in which I pick relevant Stories and Defects to discuss from the previous Iteration. I have tried to host this meeting a variety of different ways and was never able to get a good attendance, a company lunch is a great way to get people in a room to listen to you for a few minutes. The questions I am asked about each Story, even ones I felt were well elaborated, often surprise me. People bring up a scenario that has happened in the past 2 weeks since we decided to build the Story that challenges it’s usefulness or changes how it needs to work. The Iteration Demo is the best way to validate what you are building is actually good. Be well prepared for this meeting, don’t use slides, have the software up on the projector or web conference for people to see you clicking around, and don’t rush through. The best questions usually come right as I am about to move on to discuss the next Story.
9. Control Product Rollout and Production Deployments
Each company is different, you may have a Product Marketing person that helps you announce new features, you may publish to a Customer facing Product Blog, you may do nothing, in any case you are still managing the rollout of features including what code is deployed to production and the timing of everything. I include a brief summary of how each feature will be rolled out in my Iteration Notes (see 6.) as we roll some features into some products and not others. Every Monday, the entire team has a Production Push meeting in which we review each SVN checkin to make sure it has been tested and is ready to go to production. Although the Developers and QA team members are the ones talking and our ScrumMaster leads this meeting, the Product Owner is making the final decision of what should be deployed.
Summary
This list above assumes the prerequisites for being a Product Owner are already happening: absorbing everything about your industry, engaged in everyday discussions about product ideas, using the software you build, using lots of software you don’t build and so on.
Are you doing all of these things as Product Owner?
Kelly Taylor's Blog 