PBI attributes for maximizing value
If you had to choose three product backlog item attributes best used for maximizing product value, what would they be? Obviously the value proposition as documented in user stories using the As a <role> I can <action> so that <outcome/value> would be one I'd choose, along with acceptance criteria. What might the third one be? Or are there others to consider?
From the scrum guide:
The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.
The PO could use evidence based management and use key value measures relating to the current value and unrealised value key value areas to determine how best to maximise the value of the product.
In regards to product backlog ordering, this is solely up to the PO to decide what factors to use when ordering the product backlog.
I would actually not choose the User Story format you used. I am not a big fan of that format as teams frequently get so caught in the format that they don't convey all of the needed information.
My choices are driven by this paragraph from the Scrum Guide section that describes the Product Backlog (emphasis added by me to indicate my choices)
Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event. They usually acquire this degree of transparency after refining activities. Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.
A description that accurate conveys the problem or functionality that the development team is being asked to address. A description that provides clarity on why the Product Backlog Item exists. This does not have to be story format and, in fact, there is a lot of information that doesn't fall into the story format.
An order that will maximize the work that the Developers do. Not a priority, an order. For example, there could be a new feature with the potential to triple the customer base for your product which the Developers have estimated to take 6 weeks. That would be very high priority. But there could be a bug fix that would correct a problem 99% of your existing customer base that the Developers say could be done in 2 days. In my opinion, the good will achieved, convenience provided to your existing customers, and short duration to completion would make me order this above the new feature work. If there was a code refactor project that is estimated to take 2 weeks to complete and would allow the Developers to deliver your new feature in 4 weeks instead of 6, I'd order that one above the new feature which is high priority. An order is valuable.
A way to indicate the relative size of the effort based upon the information you have available today is useful in helping Developers forecast how much work they feel comfortable taking into a Sprint. But once the Sprint begins, the sizing no longer matters.
These 3 attributes have been the most useful to me as a Developer, a Scrum Master and a Product Owner.
I'd wonder why product ownership was being constrained to just three value measures. Challenging those constraints could be most immediately valuable.
A Product Owner is an entrepreneur, and should have freedom to maximize value using whatever terms they deem to be appropriate. Things to consider for each Product Backlog item might therefore include the contribution to entrepreneurial flair, innovation, and organisational agility.
Hello,
As a <role> I can <action> so that <outcome/value>: This is just a format to write a user story in an understandable way for all the stakeholders.
And Acceptance Criteria would be useful to approve the requirements at the sprint end and to testers when they will write the test cases after the sprint planning meeting.
So, I think this is not enough or relevant to maximize the value of PBI.
Obviously, PO is the responsible person who knows how to generate business value for customer or client.
Nowadays, we are using many online websites like "aha.io" or "productboard.com" type of website that would be helpful to track product roadmap, customer's ideas, feedback, score etc., and based on that PO will prioritize the PBI to generate the best business value. So, this would come first before the user story and acceptance criteria.