As a product owner and business analyst I used to measure my productivity by how many features, epics, and stories I brought to the table for a backlog grooming session. I used to pride myself on well written stories with acceptance criteria that met a ‘Definition of Ready’.
This was my role, my responsiblity, my contribution.
Over time though, I noticed that I was spending a ton of time writing backlog items and building artifacts to reflect my own vision of how things should work. I owned and lorded over the backlog. It was mine. Real pride of product ownership.
Only this type of work didn’t serve me. It actually stopped making sense. User stories should be a reflection of user need, not a reflection of analyst wordsmithing.
In my fury of story writing to meet project deadlines, I was out of touch with the user.
This type of anti-pattern can happen quick: You get funding for work; your boss asks if ‘requirements are ready’; and then you commit to dates. Within a week (if you’re worth your salt), you have a fully ‘groomed’ backlog ready for walkthrough. Users be damned, we’re going to get this project off the ground!
What I’m proposing here are 3 principles to get back-to-the-basics, to include your customers in product design, and to move past a few bad habits (born out of exigent project demands):
1. Product Owners should not lease the product.
A major part of product ownership is having a clear product definition. This starts with right-sizing the product. Too many teams define their product based on project deliverables. This leads to murky team definitions and scenarios where a single product owner cannot speak for the success of the whole.
Product owners should represent a single voice of the business. This usually requires that the product be right-sized with a defined target user base. From there you can build a product backlog that can be easily prioritized and negotiated.
Beware of product backlogs that have competing requirements that cannot be resolved, or where items are stack ranked based on the loudest voice in the room. If you are building to make a single individual happy, you have started to lease the product.
2. Backlogs are optimzed for Value Delivery.
You can take back control of the backlog by logically stack ranking user stories according to the relative value they can deliver per unit of DEV effort. I refer to this measure as Value Delivery.
The idea is a simple return on investment calculation, where the highest ranked backlog items deliver the highest ‘Value Delivery’ based on business value and level of effort (LOE) estimates.
Value Delivery = Value / Dev LOE
Value. Survey your user base to arrive at an average value estimate for each backlog item. A simple value scale helps here: High-Med-Low, Must Have-Should Have-Nice to Have, Today-Tomorrow-Next Year. Standardize each bucket on a numeric scale (5–3–1 for example).
*If you get multiple Value responses for a given item, take the average of all responses and round up to the nearest integer. 2’s and 4’s are acceptable here*
Dev LOE. Independent of the end-user survey, socialize the backlog with your Dev team(s) to get a swag estimate for each backlog item. Align on how to estimate if you have multiple scrum teams. (T-shirt estimates work well). Again standardize on a numeric scale (XL: 40+ hours, L: 24+hours, M: 16+hours, S: 8+hours, XS: 4+hours).
Reorder the backlog and groom it once more with all stakeholders, focusing only on the highest value delivery items.
Optimizing for Value Delivery acknowledges both the business/customer and respects the technical team’s ability to estimate and plan their own work.
3. Write user stories with your users.
I recognize this one may be controversial. But I find that you can open the aperture just that much more by empowering users to contribute in product design. There is a fine line yes, but involving the right set of passionate users can go a long way to refine the product vision and to deliver real value.
Good product teams may have already defined focus groups or power user groups. Use them. Call on them to help you add detail in user story workshops. No longer will you feel awkward writing ‘As a <insert job title other than mine>, I Need, So That …’.
Get back to the basics by involving knowledgeable users who are not burdened by budget or decision-making. Get the ideas on paper and then move forward.
Adopt an all-comers approach in your next story writing workshop. Include stakeholders from all impacted teams, invite your power users, invite the decision-makers too. Incorporate all voices in the room so that your user stories reflect the true ‘voice’ of the business.
Product Ownership does not have to be a feudal exercise. The more inclusive you are in your product definition the more successful you will become with delivering a return on your DEV effort. Good luck out there, and let me know what principles guide your team in product and sprint backlog grooming.