Some comments on story collaboration sessions

I recently ran a course for product owners and said that the product owner or BA facilitates the elaboration, slicing and general understanding of stories WITH THE TEAM.

Some of the crew asked how to do this and the following is what we came up with in the class.

Firstly – you can hold a weekly “Elaboration meeting” where you have some or all of the team meet with you and break stories down however you want.

One approach is to simply break the stories into acceptance tests, maybe using “given – when – then”.

I published an article on doing that here  and there is an even better discussion of using acceptance tests at the “beyond Requirements” website here .

But sometimes you might want to do something a bit different.  So here is a potential plan of attack.

1. Get a sheet of paper and draw a space for the story.
2. Choose a set of questions to ask and then break the story down using those questions
3. Rush off to you computer and build from what you remember … or document what you discovered as acceptance tests, prototypes, tasks or whatever you think is best.
4. You can split into mini-teams if you want – in which case you do step two as a mini team and then explain your reasoning to the next group.  They then attack your thinking and you update what you documented.

Here are some possible sets of questions:

Simplified Kano

Kano had some great thinking and you should research him if you want to be a great BA or PO.  But if you are lazy then just try the following approach that might work well with personas or different user types.

Kano said that things that are loved by on person might be hated by another one.  He also said that sometimes you won’t miss something if it is not there but love it if you see it.  Similarly you might expect something and be upset if it is not there but bored if it is.

So grab a series of personas or focus group users and get them to rate the story on how they would feel if the feature was there or not.  Then brainstorm ways you could meet the needs of both users or which you would prioritise.

Specific questions to make you think

I adapted the following questions from the Beyond Requirements site (questions to ask).

Just run through the questions and then decide what to capture.

Dodgy error proofing

Here I use some questions from the international standard for being scared but you can also use the questions from the international standard for being stupid.

Simply run through all the things that can go wrong.  Then look at how you can inform a user, stop a user from making mistakes or at least help them know it went wrong and then recover.  Even though it sounds like you are only looking at errors, you will actually find this works well for understanding how a user might use a system and how to make it easy (and safe) to use.

This is my favourite approach of those listed here.

CRUD MOSCOW

Finally you can use two acronyms

The first is CRUD.

For each noun in the story (“user”, Want to “thing” so that “thing”) you ask if you need to create something for it to work.  Then you ask who might Read or access the information later and what information people need to access to complete this story.  Then how can they update what they have entered and how can the delete/archive what is there.

Then you use MOSCOW.

What MUST happen for this story to work?

What must not happen?

What Must the user be able to do?

Then replace “MUST” with “Should” and “could potentially” and “Won’t or BETTER NOT”

Not very sophisticated but it is easy to do.  Try it with the crew and let me know if it works