I was watching a television show recently about Air Traffic Controllers and how their job has evolved over time. It was interesting to note that their job has been basically the same since the beginning where they have to track many planes at once and service each one’s specific needs. In thinking about this, it struck me that the role of Product Owner is much the same.
Of course it is well known that the Product Owner is responsible for preparing the Product Backlog for Sprint Planning but there much more than that. A Product Owner represents business needs and is a conduit for requests from the smallest of defect fixes, to product enhancements, to completely new initiatives.
All these requests must flow through a process managed by the Product Owner which is where my analogy of an Air Traffic Controller comes in. The following illustration helps to explain the comparison. There are four “zones” a Product Owner must pay attention to, giving each a slice of his overall time and making sure not to leave any one unattended for very long. The successful completion of a request is dependent on the Product Owner managing all four zones so that each request can “land” and call the journey complete.
Zone 3 – In a Holding Pattern
All work for a Scrum Team begins by entering Zone 3 regardless of whether the Product Owner himself created it or it was a request from elsewhere in the organization. These requests will typically be unstructured and contain varying levels of details. They could be merely vague ideas mentioned in passing by a coworker in the hallway: “We should do something about that problem we had last week.” or be very specific requests: “I need a tool to decrypt files for diagnosing problems.”
When the Product Owner receives these requests there’s a minimum set of information that should be captured.
- What is being requested.
- Why it is wanted.
- Who is requesting it.
- The urgency level.
- Who can be contacted for additional details.
This information will be used to triage requests and help determine its place in the Product Backlog. When the request is larger in scope or will be visible to the business, it should also be tracked on the Product Roadmap.
As these requests collect, the Product Owner will need to dedicate time to grooming them, refining what is wanted by spending time with the requester. When the Product Owner has enough of an understanding of what’s needed, he’ll be able to create a series of backlog items representing the original request.
Zone 2 – Forming Up for Approach
The backlog items in Zone 2 now represent the request but they will still need refinement. The Product Owner may need to create a project kickoff presentation, data lookup tables, final copy (text), mockups of user interfaces, et cetera. These additional elements will be necessary for the Scrum Team to fully understand what each backlog item asks for. Creating all this material will consume plenty of time and may require consultation with others in the organization since the Product Owner is unlikely to be an expert in all areas.
Additionally if any backlog items require coordination with outside resources, such as the ordering of hardware or negotiating to have a resource available, the Product Owner will need to line these up.
As backlog items become complete enough to be reviewed by the Scrum Team, the Product Owner will present them during a Story Time meeting. This process may be as simple as explaining each item or giving the team a presentation regarding the big picture and what they’ll be working on. Feedback from the team will help refine each item further.
Zone 1 – On Approach
Backlog items in Zone 1 now have all associated material ready and the Scrum Team has seen and provided feedback on each one. Also, any outside resources will have been coordinated with, and committed to, providing the support needed. At this point each item’s final position can be established within the Product Backlog.
Once backlog items are in this zone, they should not be bumped from their position for the following reasons:
- The Scrum Team is familiar enough with each item and any delay will result in their memories fading, requiring another review at a later time.
- The Product Owner’s memory of the details may also fade, requiring he re-familiarize himself with each backlog item to be ready for Sprint Planning.
- External resources (personnel, equipment, processes) have been lined up and rescheduling may not be possible in the short term.
- Events or processes such as Sales Training, or an advertising campaign dependent on delivery may not be easily postponed.
- Any expectations management had about delivery dates will have to be reset, potentially creating disappointment.
However, just like with real airports, where emergency situations require airline traffic be put on hold for a plane in trouble, backlog items for urgent business needs will occasionally be wedged in at the top of the Product Backlog. In these cases the Product Owner and Scrum Team will just have to deal with the new work as best they can.
Ideally Zone 1 should have enough backlog items to supply a Scrum Team with two sprints worth of work. Having this surplus ready is good for when a team’s capacity has opened up and they are willing to take on additional items. The Product Owner will have to continually focus on refining backlog items in this zone to ensure enough work is available.
Zone 0 – Landing
In this zone, backlog items have been selected into a sprint and the team is actively working on them. It is important to allow the team to complete this work but if absolutely necessary, they can negotiate a change in sprint scope.
To support Zone 0 the Product Owner will have to be available during Daily Standup meetings and address any questions or needs that come up. There will always be questions once the Developers begin implementation and no amount of preparation ahead of a sprint will eliminate them.
Managing the Airspace
A Product Owner, just like an Air Traffic Controller, will have to monitor numerous requests and backlog items throughout the process. It can be overwhelming to pay attention to so many things each day leading to a risk of burnout. A workable strategy involves blocking off time by the hour to concentrate on one of the zones at a time. For example, allocating an hour a day to Zone 3, the Product Owner may concentrate on clearing requests out of their email, and converting them into rough backlog items describing each request at high level. The same can be done for the other zones, allocating time as needed to keep everything moving.
The method of concentrating on one zone at a time can either be in the order of requests flowing through the process or randomly, whatever makes the most sense. It is important however that attention be given to all three in order to have enough work ready for the Scrum Team for the next Sprint Planning meeting.
© 2012 William Patrick Swisher