Using the DEEP Model for success.

Someone's desktop.
Backlog management is as simple as deep.

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 required considerable time to work 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,” today, I want to discuss a portion of what it takes to be a successful product owner: backlog management.   

When we delve into the principal role of a product owner, it becomes evident that they bear the weight of responsibility. They are the ones who guide the development team on what tasks to tackle next,  ensuring that the business objectives are met and the customer receives value.  This is not a role for the faint-hearted. It demands 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 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 when work will be finished.  The correct level of detail in stories makes it possible to understand what needs to be done instead of doing it.  Treat estimates like an educated guess instead of a quotation; otherwise, you set 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 guideline for managing work for your Agile team, giving you a leg up on other product owners.  

Next time, we will have a discussion on how to write user stories.  

Edward J Wisniowski

Edward J Wisniowski

Ed Wisniowski is a software development veteran. He specializes in improving organization product ownership, helping developers become better artisans, and attempting to scale agile in organizations.
Sugar Grove, IL