Agile has three primary roles, the development team, the scrum master, and the product owner. Since the authoring of the agile manifesto, the reformation has done an excellent job encouraging the development of craft among software developers. The reformation has also spent considerable time working on the professional development of scrum masters. The weak link has been the development of product owners. Understanding this, I have dedicated most of my career to helping product owners improve. I call this “healthy ownership,” and today, I want to discuss a portion of what it takes to be a successful product owner; backlog management.
When I discuss the principal role of a product owner, I say they are responsible for telling the development team what they need to work on next. A product owner is also responsible for the business, ensuring the customer receives the value. It is a demanding role that requires diplomacy, expert business knowledge, and a full-time commitment.
Unfortunately, most organizations do not feel this way and often provide product owners who work part-time while doing other accounts receivable or shipping tasks. A product owner should also have the authority to say “no” to others but often are subservient to executives. The minimum requirements for a product owner are full-time commitment to the role, executive-level authority to set priorities and say no, and finally, the ability to work diplomatically with people inside and outside the development team. It is not an easy job.
The first order of business is to create a list of work that needs to be done by the development team. It is called a product backlog. Roman Pichler wrote a fantastic book on product ownership and scrum entitled “Agile Project Management with Scrum.” In it, he outlines a helpful framework for organizing a product backlog. It is called the DEEP model. It is an acronym which stands for –
I have discussed these backlog qualities in more detail in previous blogs. I have included links to the original articles to review at your leisure.
A detailed, estimated, emergent, and prioritized backlog is a recipe for success. Estimated stories allow product owners to answer better the question of when work will get finished. The correct level of detail in stories makes it possible to understand what needs to be done instead of doing it. Just make sure you treat estimates like an educated guess instead of a quotation; otherwise, you are setting yourself up for unnecessary stress. Backlogs are emergent because uncertainty around a project decreases when you get close to completion. Prioritized because if nothing has a priority, then everything has a priority. Lack of prioritization will transform any project into a carnival of chaos, so you must be sure you are doing things in a set order.
Using Roman Pichler’s DEEP model is an excellent working guideline on managing work for your Agile team and giving you a leg up on other product owners.
Next time a discussion on how to write user stories.
No comments:
Post a Comment