How do you remind your Scrum Product Owner about his promises/actions?

Question

** EDIT: Rephrased the question to re-focus **

Our Scrum team meets as seldomly as possible, but we meet with the product owner every chance we get. We track everyone's agreed action points (particularly theirs). We are 100% agile, but our product owner lives in traditional world, we remain off-site. We facilitate him in crossing over to our fast-paced world.

There's not much wrong. The team and the PO are in good spirits. PO is present at every meeting and positively energized. Just imagine this person as a 70 year old, slow grandpa, who is forgetful, yet kind. In reality he isn't, but he is used to a working environment (public servants) that is much slooooower. Manyana-manyana etc.

It is frustrating for my team to cooperate: PO lives in a non-prioritized environment, and everyone in it has learned the productivity-technique of NGTD (Not Getting Things Done). He WANTS to, it's just that he forgets or 'sinks' somewhere along the away.

We have experimented with

• a text file, maintained by the Scrum master (low-tech), which he broadcasts by e-mail every day
• JIRA, our issue tracker. Turns out this is nice for programmers, but too steep for 'regular people'

I Googled for Issue tracking webtools but came up empty handed: All tools are aimed at IT issue tracking, instead of meeting action point tracking/planning for mere mortals. I did find TODO-lists like RememberTheMilk, but they don't track comments, and - to be honest - I doubt we could get our product owner to use it (too complicated).

We have three requirements:

1. Register action points, assign to a team member and a deadline
2. Offer anyone to 'comment' on progress of any action point
3. Do not build our own tool from scratch

We do not need: - impressive authorization models, - multi-project, - workflow, - crosslinking.

Is there any trick/tool you use to assist your product owner 'fly' like the rest of the rest of the team?

Communication before tools I agree with the general consensus that one should not try to apply technology to a communication problem, however in this case I am merely looking for a tool to save me time in setting up prioritized lists.

I found www.thymer.com today, may be what I am looking for. The guys are cool. It is getting rather feature-bloated though.

Answer 1

IMO, it will always be a constant battle but I applaud your persistence in coming up with a "middle" solution. This is a battle I basically fight in one form or another every day.

How about simplifying it by using some tools he may use already, like Microsoft Office Tasks or One Note? Alternatively, you use a free portal product to help with that as well.

Answer 2

If you want action, you're going to have to start talking the Product Owner's language, and you're going to need to attach consequences to the overdue items. Not in the "we'll send you to bed without dinner" or "we, the engineers, will be unhappy!" sense, but in the "here's what the impact on the project in dollars/euros is" sense. Money tends to get product owner's attention in the way that "whining from those pesky engineers" doesn't. You're now speaking their language.

{Something} is due on {date}. Every day we delay on {something} costs the project ${amount}.

This is independent of the tool you use to communicate with the Product Owners', but the classic mistake we make over and over is thinking that the tool is sufficient.

Answer 3

I'm not convinced that the choice of tool will necessarily bring about an improvement on the part of the product owner but I'm sure that a poor choice will only make things worse.

But it sounds to me like your 'product owner' isn't on-board with the role s/he has. I suggest that a (very amicable) sit-down, be it in-person (best) or using some "go to meeting" video solution or via phone-con if that's the best you can do. Everybody's got to be on the same page or you're going to have issues moving forward without delay.

I'd explain to the product owner in this meeting that A) they've got a vital role and B) there's got to be accountability in place for everyone and C) whatever tool it is that you choose to use to keep folks accountable and track progress, it needs to be used and used universally.

Time delays = money and the definitely possibility of failure.

Whatever tool you choose, everyone has to be on-board. My shop uses very lightweight tracking tools and relies on a "less is more" approach. Like you're group, we have few meetings and only when there is need.

Answer 4

I looks like You have some serious problems that can't be solved by some piece of software. Off-site Product Owner can work, but only when the person is aware of his/her responsibilities.

Your PO does not seem to care about the project. You seem to look for some easy to use software, but You mention that RememberTheMilk is too complicated. From Your description it seems that none piece of software is going to solve Your problems. I'd rather recommend dragging PO to the Sprint Retrospective and make him/her aware of problems caused but his/her lack of commitment and unresolved issues. Looking for better software You're probably fighting symptoms not the cause.

As for issues tracking, we successfully used TWiki + ActionTrackerPlugin. It's simple, yet working.

GL with Your Scrum.

Answer 5

We use FogBugz to keep track of both our development tasks as well as our customer's tasks. Yes, it's very developer-friendly, but because its relatively light-weight on technical jargon and has a relatively clean interface, it's pretty customer-friendly as well.

We've somewhat customized FogBugz inside the database (adding new item types: Tasks and Improvements), but it works pretty unmodified as well.

• If the customer needs to answer a question re: requirements, we create a FB Inquiry and send it to them.
• If they have an action item from a meeting, we create a Task or an Inquiry for them in FogBugz.
• We don't leave it up to them to resolve inside the tool. If they don't do it, we do it for them.

The point is that we use the tool and integrate it as much as possible. When its not possible, or where the customer fails to use the tool, we use it on their behalf (recording their comments/emails, adding their decisions/requests, etc.) While this hybrid approach may not be the most efficient for us, it's definitely better than having a tool that's utilized only by the development team.

Answer 6

I'm interested in the statement "Our Scrum team meets as seldomly as possible". That means once a day. If it's less than that, you aren't doing Scrum. You are doing something called "Scrum-But" which is described here with appropriate warnings about how badly it works.

My suggestion is that the Scrum team should only accept things onto the Sprint backlog for which all precondition work has been completed. If that seems impractical, then the team should abort the sprint when they reach a backlog item for which the precondition work has not been done. That will help bring the seriousness of the consequences to the PO's attention.