Both are junior members of staff without much prior experience. Mario is taking on his first role as a Product Owner and Julia is a Developer.

How are they both supported and trained when they join their agile squad?

Julia joins a team of experienced developers, and she can spend some time shadowing other team members and learning the new technology. Her work will constantly be checked by other team members during code reviews and product demos — which will give very useful feedback to help her improve.

Mario, in contrast, has been allocated as the Product Owner for an existing development team. He’s the only Product Owner on the team, and doesn’t have anyone to shadow. There are other Product Owners in other teams, but they’re working on different projects. There’s also no mechanism for other Product Owners to provide feedback to Mario on how he’s doing. …

As a Product Owner its tempting to try and capture as much detail as possible on a user story. I might start with a simple requirement, but then end up adding loads of additional information!

Of course, we all know that a user story, at its essence is just meant to be a statement in the following format:

As a [persona] I want [a feature] so that [business value]

• The persona is the person (or sometime system) that wants to do something
• The feature is the thing they want to do
• The business value is the reason why they want to do…

In an ideal world, there should be one Product Owner for one agile development team or squad. Or at a stretch, maybe one Product Owner for two teams, if they’re working on the same backlog.

At the moment, I’m not in that ideal world. My current project has five squads working on different epics, and only two Product Owners. We both have two full-time teams each, and we try our best to help support the fifth team between us that has no official P.O.

It’s a difficult situation, because we have to constantly context-switch between the work done between each team, and end up having lots of scrum meetings. …

The Scrum Master for my team left for a new role at the end of August, and since then we’ve been without a dedicated Scrum Master.

My role is that of the Product Owner, but in the past I’ve covered some of the duties of the Scrum Master (keeping the show on the road) during holidays and illness, and so I volunteered to step in to the role until a replacement can be hired.

Ten weeks on, and there’s no sign of a new Scrum Master being hired, so it looks like I’ll be carrying on with my dual-role a while more. …

I like that we have a Definition of Ready for our stories. As a Product Owner it gives me confidence that I’ve done my job properly in analysing and communicating the requirements, and also that the team is ready to hit the ground running when the sprint starts.

Lately, however, it’s been more of a struggle to get stories to a ‘ready’ state ahead of sprint planning. Other things — often external factors — block stories from being ready. …

The whole subject of measuring performance of agile teams is a divisive one.

In an ideal world we should be looking to measure the value delivered by a team, rather than collecting performance statistics. After all, our primary goal in agile is to deliver some value to the product or customer. But measuring value isn’t easy, and it’s not quantifiable. It often can’t be expressed in numbers. And so often organisations measure other things.

All too often the most visible thing to count — story points — is the one thing that should never be counted!

A cautionary tale…

In my recent experience, I worked with a Release Train Engineer (RTE) — that seemed to have little previous experience in agile — who decided (against all advice) to measure and report upon story points. …

How often does your sprint goal or stories change in the middle of the sprint? A late-breaking requirement or bug comes in, or a manager pops up with an urgent task, and before you know it your sprint is totally overloaded. Does that sound familiar?

Teams often think they’re being agile by responding to changing requirements during the sprint — or else they feel pressurised by managers to take on extra work that they didn’t plan for. And then at the end of the sprint, the inevitable questions get asked about why the team hasn’t delivered?

“The team committed to delivering this feature. What happened?” the manager might say — forgetting that they were the one that torpedoed the sprint in the first place! …

Have you even been to sprint planning and realised that the so-called stories are a bunch of crap? One-line JIRA tickets that the team haven’t seen before?

Then you need to enforce a Definition of Ready.

We can be good about tracking the progress of stories once they’ve been added to a sprint. We track them across the board until they are done, and make sure that they are “done-done” with a Definition of Done — a kind of check-list of all the tasks that need to be complete before we’re truly finished.

But how often do we, as Product Owners, employ the same rigour with the preparation of stories prior to the sprint? …