February 22, 2013

Futurespective: “To-do & Not to do” these are the action items to get things done.

Futurespective is an incredibly positive perspective approach to get things done!
Not a lot of people are familiar with this method, although I personally find it to be one of my favorites.
I was introduced to this method a few years ago when I was wondering if I should take on a project or not, and I had to weigh the pros and cons, trying to figure out what I should do.
Usually when I start a personal coach or a team coach, I try to give the team/person a sense of control over the expected process and progress during the first few sessions, and to detect the gains and pains that the team or the person can use or over come in order to reach the project goals. It is also in my interest to set the team/person scoped into things he needs to attend that are directly related to the goal a head.
Futurespective can be a fantastic tool to serve this purpose (although we can use it for a lot more than that). It gives a good sense of control over the issues ahead and leads to practical action to enable better goals achievement.
Before we start
Some assumptions:
·         We assume that we have a team (or a person) with common interests and goals that they all want to achieve.
·         We assume that we are aware what project goals we need to achieve.
**Prepare sticky notes and a white board. After all, getting things done has a lot to do with visualization.
Let’s get practical:
1.       Ask the team to imagine a journey into the future where they are at the point of reaching their goals. Ask them to describe how this future looks like. What were the success factors that lead them to the point of success?  
**Tell them to ignore the execution phase for now. Give positive feedback and encourage the group to continue – don’t judge the ideas or the people!
a.       Write each success factor on a sticky note, and stick it on the board.
b.      Summary this session by understanding the factors that helped us get to this stage.
2.       Second phase: Ask the team to imagine they are at the point where they didn’t reach the goals.
The second phase may be the most important one in terms of making a point.
Why? What happened?
**Don’t get into solutions now.
a.       Write each unsuccess factor on a sticky note, and stick it to the board.

**Now you have a list of issues to do and not to do.
3.        Ask the team to look at the board.

a.       The ‘Goal Reached’ side of the board contains those issues we wish to keep.
These aren’t just issues; they can be policies, behaviors and rules. Following these may lead us to a better end. Keep this list visible. 
b.      The ‘Goal NOT Reached’ side of the board are those issues we wish to avoid, overcome, or deal with, a long time before they come happen.
4.       Draw action items: Ask the team/person to draw action items to keep/ avoid/deal. We can translate main pains and gains to action items as our backlog.
a.       Draw 1-3 actions items that need to be handled immediately, or assign team members to take those action items.
** Action items can be, for instance, create a list of policies, to avoid x and Y , to deal with issues and whatever.
5.       Now, all you have to do is just place your action items on your backlog and To-do list.
The techniques can be used for a lot of personal and professional issues. It can be used for example just before we initiate a new project, or just before we begin a personal journey; new work ; changes in life ; with our kids; just before a major turn over (new class, new year) and whatever we wish to tackle a head.
And as always, don’t forget to have fun while doing it.

February 09, 2013

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 :
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