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

Be like God - Kanban your way into the world

Whether you believe in God or not, the story of Genesis is an excellent example of doing one thing at a time.

As you probably know, God created our world in just seven days (vacation included)- by completing one major deliverable every day, which was made up of smaller, manageable tasks.

If you want more details, here’s the original.

Of course, things are never that simple. On the third day, God completed not one, but TWO tasks. Why? Wait for the end of the post to find out :)

So what do I mean by saying that God does Kanban and God has a limited WIP? I actually mean, that God avoids multi tasking and getting things done by controlling the load of its tasks.

Well, WIP, as you know, is Work In Progress. In Agile, it refers to all materials and partly finished products that are at various stages of the production process.

Comparing it to an industry production line: In Genesis, God put his materials in one end, ran it through the production line, and got the magnificent outcome on the other end - Our world.

Don’t take me literally,obviously, but just look at the pattern here. Each day, God selected one deliverable with a related value, and each deliverable was composed of few small tasks, each done one at a time. At the end of each day (deliverable) God took one step back, looked at the creation (demo), and took up where he left off the next day.

This is an excellent example that shows you about WIP limitations. Doing one thing at a time, and challenging yourself to achieve more according to your limits. Obviously, God doesn’t have a limit. But perhaps he was trying to teach us to do one thing at a time, by example.

Control your WIP (work in progress):  It’s simple. When we do more than we can handle, we probably won’t complete anything. Starting a lot of tasks at once, doing a little bit of everything, means that you finish late, or not at all. This also means that we have to understand what we are capable of, the size and issues we can grasp in one time.

Start finishing and finish starting.

        

Doing just a little bit from everything means you don’t do anything.

An easy example of limiting your WIP is having to attend two meetings at the same time. That’s easy. You pick one - and go to it. But what about preparing a presentation, writing a blog post, checking your email, preparing for a meeting with your team, and researching stuff for your manager. If you start all that at the same time, you won’t get any of it done, and you’ll end up missing your presentation, not answering all your emails, and meeting your team unprepared.

Now think about your kid. You’re telling him to clean his room, do his homework, feed the dog, clear the table, brush his teeth, take out the trash.... that could confuse even God :)

So how do we handle it then? How can we create our own small world, in such we can do valuable things and deliver the outcome?

Start off by making it clear (to yourself as well) that you are expected to do ‘one thing at a time’.

Then, order your tasks by schedule, priority or importance.

Make sure to start doing things with value first.

So lets take the previous example. You need to prepare a presentation next week? Start today by creating the presentation outline (‘Small task’) and send it along to get early feedback. Treating the ‘prepare presentation’ task as one big one means that your definition of done means that you have to finish the presentation today. This will affect your ability to complete your other tasks, so make sure you start and finish the scope of work as you defined it. Don’t leave unfinished tasks around.

Pick one task, complete it , and then take the next task in line.  In time, you’ll see how many tasks you can perform at the same time, but to start off with, it’s better to complete one task at a time, than start five, and not complete any of them.

In industrial factories, an incomplete cycle of work is called inventory. Factories can’t sell inventory. Inventory takes up space, which you pay for. Inventory needs to be maintained, which you pay for. Inventory is waste.

In our personal life, we pay for that wasted inventory with delays, stress and overtime, just because we try to keep up with too many tasks.

Context switching (jumping from one task to another without completing either) is another way to get little or no value from our tasks.

A nice story a friend just told me the other day about a typical Kanban situation at home illustrates another example of the same problem:

“It was Friday noon, and we were preparing for our daughter birthday party. I was with my hands in the pizza dough, and my wife said: I can’t really help you, so I’ll bake a cake for us to eat during the week. In theory, there’s no problem. But when I needed the blender, it was dirty with chocolate and I had to wash it. When I wanted to use the oven, I had to wait 40 minutes for the cake to be done.

I should have told her to just relax and drink some coffee, or put some music and chat with me, instead!”

The value = daughter birthday party ➔ pizza : was not achieved

The resources= help from others with the blender, oven. : was not available

Over doing =using the oven as a resource to bake a cake while at the same time the pizza (which holds more value) needs the same resource.

Following the concept of ‘doing one thing at a time ‘ will be made easier when you visualize your tasks on a task board. The task board will help you see your tasks, prioritize them, understand your limits and challenge yourself toward improvement.

So…  doing one thing time,  it’s easier  when , We understands that :

1. When we do more than we can handle, we probably won’t complete anything.
2. Context switching (jumping from one task to another without completing either) is another way to get little or no value from our tasks.
3. Doing just a little bit from everything means you don’t do anything.
4. Start finishing and finish starting.

So the actions applies will be:

1.       Visualize your tasks. Use a task board.

2.       Set priority to the things you need to do (see important vs urgent)

3.       Pull one task, complete it , and then pull the next task in line. make sure you start and finish the scope of work as you defined it. Don’t leave unfinished tasks around.

4.       Divide big assignments into smaller ones that have value (see how God took two small tasks on Tuesday?)

5.       Understand your resources and limits demanding to perform the tasks.

6.       Stick to doing what has the most value – even if it means not doing something else.

7.       Look back at your results. Retrospect and change  if necessary

8.       Learn and adapt to your abilities. Once in a while, challenge yourself to take more tasks (although not in parallel!), just as God did on Tuesday.

Enjoy  ☺

Read more:

• http://www.investopedia.com/terms/w/workinprogress.asp#ixzz1xkAVzbP
•  http://www.webopedia.com/TERM/M/multitasking.html
• http://searchsoftwarequality.techtarget.com/definition/WIP-limit
• http://blog.agilebuddy.com/2009/06/stop-starting-and-start-finishing-a-successful-lean-philosophy.html

Read more in this blog:

●              Prioritize yourbacklog

●              What is Kanban – how to get things done using the tasks board

●              Definition of done

●              Time management games

●              Visualization & sticky notes

●              Task board

Keep It Simple, Stupid

Simplicity is key for any Agile activity.

You’ve all heard about the KISS principle. How does it relate to Agile? Well, something which is easy to understand or explain is simple. Something that is hard to example, is complicated. Simple, right?

“KISS is an acronym for the design principle articulated by Kelly Johnson, Keep it simple, Stupid!  The KISS principle states that most systems work best if they are kept simple rather than made complex, therefore simplicity should be a key goal in design and unnecessary complexity should be avoided.”  

From Wikipedia

Kiss is also an awesome rock band

After all, Agile is a set of principle and practices collected over the years, proven to improve quality and efficiency. Now, as I’ve said about a million times before, I find that almost everything can be related to Agile. I mean, it’s just so fun! You have so many ways of using it, and improving on it, that you can adapt it to almost everything you do in life. Our home, our family and as a personal management method.

Of course, adapting Agile to your needs doesn’t mean that you can toss all the Agile rules and principles out the window.

One of them is the KISS principle – KEEP IT SIMPLE STUPID.

In my years as Quality Director, this was a key principle for me. It is so easy to complicate a software solution, to over analyze, and over test it, even when it’s not necessary. I learned that keeping things simple was much more efficient. Your boss likes to keep things simple, because, frankly, it takes less time and is cheaper to do. Your client likes to keep things simple because it’s easier for them to use.

The same goes for our kids. Start simple - and they will learn more, adjust faster, and understand the complicated issues better once they know how to keep them simple.

So how do we help our kids keep it simple?

1.       Understand your limits. (Spoiler) Superman isn’t real. Don’t expect to be able to do everything he does. You can’t do 15 tasks at once, and finish them all in 30 minutes. Don’t try.

2.       Visualize. Draw squares, put sticky notes on the board, whatever works for you. I’ve written about keeping thins visual before - it’s just that when we see things, we deal with them better, and it’s been well known for many years that visualization is key to success and better learning.
Imagine your child needs to be get ready on time in the morning. Simply visualizing the things he needs to do will make it much easier for him to understand.

Of course, you need to be careful of over visualization. Short and simple tasks may do the job. Don’t include too many details in each task, or over task.

3.       Divide large tasks into smaller tasks. For example, a big history exam can be divided into few small digested tasks every one hold only few hours of learning scope. Yes, adults and teenagers may use this as well. Instead of a ‘learn for the exam all week’ task, you have separate tasks. Choose simpler solutions to complex problems and break complex solutions down.

4.       Divide your obstacles and problems into smaller problems, so you can tackle one at a time.

5.       Understand the definition of done. It’s usually easy to see when small tasks are done. For example, the ‘Read Page 3-10 in the history book’ task is done when pages three through ten are read :). Bigger tasks are harder - so make sure you know what you mean by ‘Done’.

6.       Do one thing at a time. Work on the highest value work at all times .

7.       If you don’t have to complicate matter, don’t. Don’t over elaborate, don’t do tasks you don’t need to do, and if you don’t have to see how long a task has taken, just don’t.
We prefer to keep Agile at home as simple as possible. I have seen enough cases where it gets too complicated. Charts, reports, measures, too many principles to remember - this is where people get frustrated.

The Agile principle is easy to grasp. 1 whiteboard, 3 columns, 5 packs of sticky notes. That’s it. Sometimes Agile is presented as very complicated, even more so, when we talk about something we use to manage both software projects at work and our family lives.

I want my board to be simple, and my methods to be simple. In most cases I won't even use personal measures, personal cycle times and WIP. Those principles are all well and good in the industry, but can pose a big difficulty when I come to manage my own tasks and my children’s tasks. Use complicated reports and measurements when you manage that software project.

8.       Your family is the one who needs to understand the task board. No one else. I’ve seen task-boards for families with ten children that cover house chores, baths, shopping, and look like the plan for developing the next Facebook. But they understand it - and that’s what counts.

Bottom line? Keep it simple!

The Definition of Done - How to use Agile to help our kids do their homework

I’ll start off this post with a revelation. Ready?

Children aren’t born knowing what we expect from them.

They aren’t telepathic. Just as we aren’t born knowing how to be parents, children don’t know what we want them to do. If we want our family tasks complete, we need to define the rules and boundaries.

Think about it for a second. How many times did you ask for someone to do something, and when they say they’ve done it, we find that what they did, and what we THOUGHT they should have done, are two different things?

I managed a team myself, and I know that sometimes I need to be specific, and make sure a task’s DOD (Definition Of Done) is clear. I find myself many times working with the team and with management to define the work procedures to follow in order to produce a quality product - procedures such as safety rules, delivery procedures and so on. One of my unwritten rules is that the riskier the task is, the clearer the definition of done needs to be.

The same thing goes for our homes. For example, when you take the car to the mechanic, you expect the car to meet safety standards. You pay your bills when specific DOD terms are met - the oil is checked, the car is made ready for the winter, etc. In this case, failing to meet those DOD terms can cost us our lives!

Of course, there are tasks that I personally categorize them as risky tasks, but of course, have nothing to do with safety. Tasks that can result in unnecessary arguments, for example, should also have clear definitions of done. For example, if you ask your kid to tidy his room, make sure you understand together what ‘tidy’ means. Otherwise your kid will tidy his room to his satisfaction - not to yours.

So, homework, for example…

How do we take everything we’ve just learned above, and apply it to helping our kids with their homework?

Homework can be the source of endless arguing around the house, so applying the Agile mindset to getting homework done, just aims to make things happen.

 Visibility:

See what you want to achieve by visualizing it. First of all, you know that it should be on the task board. Even if you don’t use Agile, the ‘homework’ task has to be out there. Don’t hide from the fact that your child needs to do his homework. When we see it, we relate to it, and we increase the probability of the task being completed.

 Take it seriously and be consistent:





If you don't, they won't. You are the parent and if you think it's important, then it is - and your kids will pick up on that. 

Be specific:

What does ‘Do your homework’ mean?
Does it mean sit in your room?
Does it mean write in your notebook, and not solve questions without writing?
Does it mean that your notebook has to be tidy?

Set the rules:





You are the parent. The Definition of Done isn’t just for our child, but for us as well. There are rules beyond the task that we as parents need to keep as well.

Take, for example, a factory that builds airplanes. Every day they need to construct 50 airplanes - but no one is in charge of making sure that broken tools are replaced. Do you really expect the factory’s workers to be able to churn out a consistent number of airplanes when their tools keep getting broken, but aren’t replaced? You don’t. The same goes for your children. Just as an example, expecting them to work four hours a day, doing their homework, is just unreasonable, and won’t do much for future motivation. Not having a suitable place to do their homework, will also affect their ability to complete the task.

Here are some examples of rules from my own personal experience that can help define the homework tasks and help our kids achieve them.

1.    Have them start doing their homework around the same time every day, and in the same place (that’s suitable for homework, of course).

2.    Be around if you are needed.

3.    Don’t make comparisons. Some kids have an aptitude for math, others flourish in History. Comparing the two is not just unfair; it also means that they will both under-perform. Just the same as when you interview new employees - they might have the same qualifications, but they are two different people with different personal advantages.

4.    keep a tidy notebook

5.    And more...

 Don’t forget the ‘continuous improvement’ maxim. 




Don’t just deal with the ‘here and now’ aspect, talk over the homework issue at your daily family gathering and weekly retrospective meetings. Talk about how your child plans on visualizing his homework in the future.

Talk it over. Agile is all about mindset, and Agile at home is all about dialog.



Understand the difficulties in doing the homework, and be there to help (when needed only). The daily meeting is the place to talk about the homework - just like any other task, and not as a focal point for the entire family, a problem with the ‘why don’t you ever do your homework!’ kid.

The bottom line is that 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.

The fun way :)