Getting things done with user stories As actor stories.

By now you know that Agile isn’t restricted to software development. Neither are user stories. They can be used for personal goals setting or team work agenda outside the IT industry.

** In this post, when I am referring to a ‘team’ it may also be relevant to an individual applying agile.

 A user story is defined as a card with a short description of the users’ desired outcome, leading to a practical outcome, which is completed in a relatively short period of time.

User stories are simple, and provide small doable chunks of the whole project that need to be delivered. It makes sense what is expected out of it.

A user story is then divided into a list of practical tasks – ‘done’ or ‘not done’. Completing them completes the entire user story.

So basically, the concept of a user story can be used anywhere. We just need to understand the principle behind a user story, removing the whole ‘software development process’ for a while.

Think about the user story as a ‘goal’, and then add actors and an expected outcome that brings value to that actor. Now you can easily get things done faster and related to the initial intent (the actor desired outcome)

What is a user? A user can be anyone that is interested in an outcome, and requested it. It can be a student, a mother, a customer – anyone, anywhere. We’ll call the user an ‘Actor’ for now.

Let’s take an example from day-to-day life– baking a cake. Yes, ‘baking’ as in baking, and ‘cake’ as in cake. No metaphors involved.

This is taken from a conversation with a colleague:

• Who needs this cake?
• My mom. It’s her birthday tomorrow.

• What kind of cake?
• Well, it is her birthday, so it should be a special cake.

• What does your mother think a special cake is?
• I think she’d appreciate a cranberry cake.

• hat kind of cranberry cake?
• Wow, well, three layers. With tons of chocolate as well. She’d love that, and you know, she would appreciate the attention.

So my actor (user) story is: Bake a special, 3-layer, chocolate covered cranberry cake. Want to guess the definition of done? J

The user story is broken down into tasks – like so:

• The ingredients
• The recipe
• The baking process

In the high-tech industry It is the product owner’s responsibility to create user stories so we can start working. But again , product owner is  just a role , of course, anyone can write them, as long as the ‘product owner’ is involved and approves.

Actor  stories can be written on a note or sticky notes and be ordered on a wall according to their importance to perform.

Actor story format should reflect the fact that we need to get inside the actors’ head, walk the path they will take, and set our goals accordingly.

In software development, user stories are treated more like goals. User story formatting changes according to the business needs at the time, but the principles of keeping track of whether our user story is “ready” are pretty much the same.

There are many debates about how a user story should be written. I don’t think that our goal is necessarily sticking to a certain format. Our goal is to follow the actor as he walks through the process, and understanding his needs. That will lead to a successful completion of the user/actor story.

So our thinking guidelines should be along these lines:

As an ‘Actor’ I would like ‘What’ so I can ‘Why’

For example: As a ‘Student’(Actor), I would like (What) ‘to be able to write in my textbooks’ (Why) so I can ‘avoid copying everything from my notes’.

Of course, not all Actor stories need to be formatted this way. You only need to be sure that the outcome is clear and we know what is expected. Remember, this isn’t a software development story so we may vary in the way we define it. But, we do need rules to define how we work with Actor stories, define them, and follow them.

The Actor story should be (Bill Wake):

• I – Independent – so we can start and finish it completely as an item with independent value. We can also schedule and implement them in any order.
•  N – Negotiable- it’s not a definite explicit call for order and command. It’s something we should talk about. It does not have to be detailed as long as we know the intent.
• V – Valuable- reflects that value to the relevant ‘Actor’. It should include all the information to hold an end to end value.
• E – Estimable – can estimate the effort to make it done, not in great detail, but enough to size it.
• S – Small – small enough to complete it in a reasonable time. Usually no more than a week’s work.
• T – Testable – We can verify that it is what we aimed to achieve, which is why every story should include a definition of done.

An Actor story can be split into smaller Actor stories, if they are too large, or the Definition Of Done is too big to achieve in relatively short time frame, or if the Actor story has more than one value to it, and so on.

Actor story - Definition Of Done :

Every story needs an ending. We aren’t telepathic – we don’t know what’s expected from us. We have to be told ‘this is when the story is done’. Every task or assignment needs to have some kind of a boundary that defines it as being done.

I’ve managed teams myself in the post, and I know that sometimes you need to be very specific, making sure that stories’ Definition of Done is clear.

It’s the team role to understand the story, as after all, it’s their job to deliver and perform.

A  good Definition of Done is one that is specific enough to understand what results are expected, and has rules, boundaries and surroundings to make sure that things get done.

For a good Definition of Done, ask yourself:

What is expected from us to show at the end of this Actor story?

How am I going to carry out this Actor story?

For example:

The Actor story is:

As a school principle I would like to understand what is the school teachers’ pain in their day to day activities with special kids so we will be able to present it to the board of committee.

What does ‘research teacher pains’ mean?

Does the outcome have to be a research?

Do we need to present our school view over the matter?

What will we see at the end when this user story is done?

Talk it over, understand what is expected.

 Remember: communication is a key.

Actor story information – the card:

Visualize your actor story on the board. When you can see it, you can address it and the probability of getting it done is higher.

How do we visualize an actor story?  Well, we can do it in several ways.

• The Actor Story card usually contains : The subject.
• It also contains the goal or “As an ”Actor” I would like “What” so I can ”why” .
• Estimation/Size if needed.
• Owner.
• Due date if needed.
• Priority – or ordered on the board according to the order of work.
• Remaining effort vs. planned effort.

Remember – on one hand, the information needs to be presented clearly, so we can understand what we need to do, who and why, just by glancing at the card. On the other hand, you don’t want to swamp team members or yourself with too much information. Keep in mind that the team or you , gathers around the board every day so we want them to look at the cards and quickly understand them.

(Between you and me - it doesn’t matter. The main thing is that the user stories are visible, and that the team sees their name on the boards, and understands what they need to do. )

Other than the team, no one needs to understand the board, so put up the cards that make the most sense to you.

Ready Actor story:

A ready story is a statement where we know that or the team can start work on this story. It is a list of criteria that announces that this story is ready for work. It is a story written in a way where the team understands the expected outcome, negotiated around the story, and the Definition Of Done is clear. The principle is to be able to define and follow those ready criteria, understanding that eventually it will help the team to perform it better, faster and cheaper according to the value expected.

Each organization and related product defines ready above what mentioned before differently and add data to it differently.

There may be projects where stories require a sketch, or a sort of budget approval, or some other data before it can be considered ready.

Actor stories should be ready two sprints in advance, to allow the team to visualize their detailed scope in advance, understand what is expected in the context of what they are doing and see the big picture.

Ordering  an Actor story :

We’ll talk about it more when we deal with planning the sprint but to make it short and simple, Actor stories should be ordered according to the value they give. If you feel that everything is vital and super important at the same time (which never happens), just let the team pick up whatever they think they should complete first.

You can easily maintain a stack of ordered Actor stories by moving the cards around in the stack as appropriate. 

Accepting Actor stories.

Actor story should start and end within each sprint. Therefore, it is best to plan the strategic of having all of those stories accepted during the sprint. The best strategy will be to work on one thing at a time according to the team capabilities.

During the sprint, when the team completes each user story, the Product Owner has to accept them. This means that the team achieved the Definition of Done, and the product owner read and accepted the user story.

To sum this up :

• A user story may be used outside the IT industry, and we suggest to refer to is as an Actor story.
• An actor story is a card with a short description over the outcome desired from the eyes of the actor, leading to a practical outcome completed in a relatively short period of time.
• Actor story format should reflect getting inside the ‘Actor’ shoes, walk the walk and set the goal.
• It better be SMART.
• Actor story should hold a definition of done (DOD) one that is specific enough to understand what results are expected.
• Order  your stories. You can just order them on the board according to the order of value given.
• Visualize the Actor stories on the board.
• The Actor story card on the board should hold just enough information for the team to understand .
• Make sure to have “ready” stories two sprints a head: a list of criteria announcing this story is ready for work.
• Work on one user story at a time.
• Accept stories during the sprint.

References :

User Stories Applied

http://en.wikipedia.org/wiki/User_story

Mike Cohn, "User Stories Applied", 2004, Addison Wesley, ISBN 0-321-20568-5

Mike Cohn: Agile Estimating and Planning, 2006, Prentice Hall, ISBN 0-13-147941-5