How do I motivate stake holders to test the sprint delivered software?

Question

One recurring problem we have in projects is the fact that the stake holders only start looking properly into the delivered software until the near the final release date even though we deploy the sprint result into the test environment every time and demo from it and keep reminding them that it's really important to get their feedback during the execution of the project and not only when the release end approaches.

Even with all this, we usually get only a couple of issues reported every sprint and 10 times more issues reported when the release is about to finish.

Any ideas on how we could motivate our stake holders to get more involved in testing during the whole project and not just when the deadline approaches?

Answer 1

The use of your software needs to be useful in their daily work. Otherwise they will not test it as it has no perceived value for them. That is my experience anyway.

One way is to implement features early that are of high practical value. E.g. making some things easier. It is often amazing how little this requires. For instance the ability to do something on a set of things (e.g. a number of user selected files or user selected items or all appropriate items in a folder and its sub-folders) compared to the requirement for the user to do something over and over again on single item. It sounds obvious, but I have heard from users of one of my open source applications that they prefer it over other programs for precisely this reason.

Another way is to put some other incentives in place. E.g. sending them a small gift when they have reported 10 bugs/issues. The trouble is of course that you risk that you only get what you measure.

Answer 2

Are you relying on your stakeholders to do your testing or do you have a dedicated test team, with representation in your scrum/team? Do you have a test plan for each sprint (no matter how informal) with test cases (unit tests don't always cut it for business level testing)?

Your stakeholders' role is to provide business level feedback on the features you've delivered in the sprint - not to report bugs, which is the impression I get of your expectations from reading your question.

Do your stakeholders attend your daily scrum/standup as observers? They don't have to go to each one, but they should at least attend your planning meetings and you should aim to have at least one stakeholder attend more than once per week. If they see progress on their pet features at the daily scrum then they may become more interested in seeing the results at the end of the sprint.

The bottom line is, what motivates stakeholders (i.e., business level people) is delivering business level value. Get them to validate your features at this level and leave the bug reporting (during development) to test professionals.

Answer 3

Is there a part of the project scheduled for the end users to use the new system? IOW, is there time for them to test it out and be shown various features and get a walk-through so that they aren't figuring everything out on their own?

Secondly, is there any way to make the releases more frequent so that there isn't a big set of changes when there is a release? That would also help possibly, keeping the releases small.

Answer 4

Why do you use the word "stake holders"? In scrum, the team is responsible to deliver the product that the "Product Owner" (singular) asks for. If the product is not fit for use that is his problem not the team's.

It sounds to me like you have stakeholders without any skin in the game and thus they are not truly accountable for the project. POs who are true owners test the software throughout the sprints because they know if it isn't fit, its their job on the line.

Find the real PO in your organization.

Answer 5

You're having an impediment here. Is it possible to have one of them as a tester in the Team ? Another possibility could be to have a member of the Team (tester or developer) working with the stakeholders to understand their needs, how they work, how they use your product... so that the Team can detect and fix the issues during the Sprint.

Removing a resource will slow the Team down, but this is to go faster in the long term and it will improve the communication between the two parties.

Also what is the nature of the issues that are reported lately by the stakeholders, are they "predictable" ? Can't they be avoided with stronger acceptance criterion for the backlog items ? Aren't they caused by some form of communication issues (do the Team and the stakeholders speak the same "language" - read domain language here ?

How do you execute the end of Sprint demo ? Do the stakeholders attend ? Demos shall be kept short, but it shall be possible to extend it to do some exploration on the product, should stakeholder will.

Oh, and ask them for feedback: "how satisfactory the Team work is ?".

Last idea, be harsh, refuse to consider items "done done" without stakeholder feedback, or add the issues to the backlog, at the risk of delaying the release, or descoping other items and explain what lead you to do so.

Answer 6

1) Showcases

At the end of each iteration, do you have a planning meeting for the next iteration?

Just before the planning meeting starts, have a "showcase" where the functionality from the last iteration gets demoed to the business. I've worked in teams where each developer is responsible for "producing" a user story. That term works just like in Hollywood - you don't have to be developing your user story all the time - but you're responsible for getting all the bits to fit together and scripting the demo. We'd get the "producer" of each story to demo the functionality of their story.

Sometimes you can get businesspeople to participate in the showcase - especially if they ask question about what they see. If they ask "can it do X" or "what happens whey Y happens?" - you can get them to try it out right there.

Even if they're not driving all the demoes - having a showcase ensures that they see what they've paid for.

2) Short, bug-fixing windows

I know one solo developer that sets relatively short bug-fixing cut-off periods. He guarantees that any bugs the customer finds within one week of delivering the product are fixed free of charge. After the first week fixes on existing work is charged at time and materials rates.

Answer 7

Taking the issues you talk about to be missing/wrong functionality rather than bugs in the software (as that should have little to do with business stakeholders) it sounds like you haven't been showing the product to the right people. If you can, invite a couple of the end users of the software to your review as they will provide invaluable feedback. I will stress these people should be the ones on the factory floor, so to speak, not executives or managers.