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 :
