PBI Workflow for POs
Recently, I was speaking with a team trying to work in a more agile way. They’re really trying to focus on the delivery of great work that adds value to their customers & users. And, they happen to have recently been assigned a new manager, who is also playing the role of Product Owner. The team is early on in their journey, and their new manager is even newer to this way of working. The manager happens to have 30ish years working a certain way and so, is finding some of the ideas that the team is trying to follow a little challenging.
This team is trying to follow the Scrum framework. We can argue if they should or not, but for the moment, they are. At least, they’re mostly trying to follow it. They’ve found that adding a Refinement meeting once a week is helping them get work ready for the upcoming Sprint, but are still having lots of issues with work not being completed during a Sprint, and a real lack of understanding for what it means for a piece of work to be ‘done’.
So today, I helped the team try to come up with Acceptance Criteria for a couple of their work items. As you can imagine, it took a while, but we got a few done. And yet, for every item, the manager wanted to sign-off that each item was complete, to his satisfaction.
It got me thinking about the value of Acceptance Criteria, and our desire for that to be what we hold ourselves accountable for delivering when we pick up a piece of work. We can’t be building to unknown criteria that might be unarticulated in someone’s head! So to help illustrate this, I drew a little workflow diagram, with the intention of helping this team, and mostly this manager, understand that when following Scrum, we need to remember that our work is incremental and iterative… And we often forget that iterative part. Iterative means we might go over the same thing more than once… We iterate on what we’ve build because we find a better way to do whatever it is we’ve built. And I really think that gets missed with teams on a regular basis.
In any case, here’s the picture I drew. I’m sure there are steps missing. I’ve wished away all of the details of how we prioritize or sequence our work. I’ve not tried to show lots of aspects of this. I’m sure it’s not perfect. But, it was really built to remind this manager, and this team, that once we’ve agreed to the Acceptance Criteria, we build to that (and then stop building). Then, we can inspect what we’ve built, and incorporate new ideas from the PO, customers, users, and stakeholders into a future Sprint, and prioritizing that new idea against any other ideas in our backlog, making sure we’re working on the most valuable, highest impactful work. Maybe you’ll find it useful?
If the image isn’t clear, you can download a PDF version of it here: https://www.dropbox.com/sh/bt05io6zbwks6ug/AACNhlFnoAkmR5_RMy_86QRwa?dl=0
