The difference between task and user story
The key to productive work is not working on more tasks, but selecting the right ones. The question is, how do we recognize the most appropriate tasks? Let's have a look at how we can achieve this.
Understand the outcome first
The best task to work on is the one that provides the most outcome for our customers or end users. The value of the task comes from the outcome the task contributes to. The first step is to identify the outcome and forget the task.
In agile development it is common to use user stories and user voice format: As a
As a website visitor, I understand the value of outcome-driven task selection and will try it, so that I'll be more efficient in the future.
Tasks are secondary
Tasks are activities we need to perform in order to deliver user stories (outcomes). The point is that the more tasks we accomplish – and the more time we spend with those tasks – the more we invest in a user story. Although accomplishing tasks may make us feel like we're progressing, doing it randomly may actually increase our costs without increasing the value we create. This is very important! Tasks alone are not valuable, they're just costs. Only user stories that we deliver to the customer – the outcome – represent value.
How to make a difference between task and user story?
Answer this question: if I only finish this work, will it deliver value to my customers? We need to know who our customers are, in order to answer this question. In the case of this article, our customer is you, our valued reader. Our goal at Scrum Mate is to make your work more efficient. The value will be created only if you change the way you think about tasks and try this method. Does it create any value that I wrote this article and I have it on my notebook? Definitely not, until I deliver it to our readers. So writing an article is not a story, it's a task. I can spend quite some time writing this article without creating any value. Value will be created when the first reader decides to at least consider this approach. There are plenty of other activities I (or someone else) need to perform in order to deliver value.
- I want the article to be grammatically correct and easy to read, so I need someone who will proofread it.
- Illustrations will make the article easier to read, so I need to draw illustrations and insert them into the article.
- I want this article to be read by people, so I need to publish it. Then I'll need to promote it to help spread the idea.
- I also want to measure how this article performed, so I need to set up goals in Google Analytics and check reports 2 days and 2 weeks after the article has been published.
The user story describes the outcome of the work, tasks define actions to take Once we've noticed that we have very similar tasks to perform within each user story, then we've identified a workflow.
Workflow : a series of common tasks
Once we've identified common tasks to perform, we won't need to plan those tasks upfront anymore. To help us with workflows, we have a very powerful tool: Boards. All we need to do is to construct a board with columns, where each column represents a status of the user story we're working on. The status can tell us what tasks need to be done next. Here is an example for a publication workflow.
- Selected: we want to work on this idea in the near future
- Brainstorm: we're generating ideas. The story can leave this column once we have enough ideas to work on.
- Write the post
- Analyze blog performance and gather insights
This is the workflow we've constructed. Once we have our board, there is nothing else for us to do other than put all user stories into their appropriate column on the board. This gives us an overview of all active user stories. The columns of the board represent the common tasks we need to perform to deliver a user story There will be other tasks than those that are represented by the columns. For example, our proofreader might advise us to rewrite some part of the article. So, we will need to create a task to accomplish that goal. In the meantime, the user story will be stuck in the “Proofread” column. It's better not to move user stories backwards on the board, and in the following chapters we will discuss why.
Don't work on too many stories at once!
It's very important to limit the number of user stories in progress. At first sight, it might look like a good idea to start a new story and enjoy the feeling that so much stuff is moving forward. But this feeling will cost us a lot. The more stories we are working on, the more time we invest into work that won't produce value in the near future. This is like building a big inventory of unfinished work.
Work can go sour!
Building a big inventory of unfinished user stories can seriously harm our productivity. Work can easily lose its virtue. There can be many reasons for that, but here are a few of them:
- The delivery of the value has taken so much time, that customer expectations have changed and they don't need it anymore. So, the time invested in creating something has been wasted or has lost its value.
- The person who started the work has been directed to another story or left the company. The new person who takes the job has to learn the context of the work from scratch.
- The customer still needs the result of our work, but their priorities have changed and they wish we would have worked on something else instead. There will be a cost of delay.
If we want to maximize the value of our work, we need to work on as few stories as possible. The fewer stories we're working on at a time, the more power we can concentrate on them, so the faster we deliver value. In an ideal world, our team would work on one user story at a time until we deliver it to our customer. In lean manufacturing this concept is called the one-piece-flow and it is at the heart of the famous, hyper-efficient Toyota production system.
Focus your attention on the end of the board
In lean production system there is a concept called pull-system. The pull-system focuses our attention on the last uncompleted item in the process and spurs us to move it forward and free up a slot for a new item. We can only start a new item if there is a free slot for it on the board. If we put all user stories we're working on onto the board, we can easily implement a pull-system. Just follow this simple rule. If someone in the team has free capacity, they should choose a task from the last uncompleted user story on the board. If there are no more tasks available in the last user story, take the furthest one to the right and work on a task from that story. Pull-system: work on the very last uncompleted user story If we follow this simple rule, we end up on working on fewer stories, delivering them faster and reducing the risk of work going sour.
There should be no task without a story
From now we should not think in tasks. We should focus on user stories (valuable pieces of work). Tasks should exist only to help us move the story forward on the board. If someone suggests we start working on a task, we should ask: what exactly is the value this task contributes? Is that value already identified and represented on the board as a user story? If so, is it the last user story we could work on? If not, are we really sure that we need to change our priorities and invest our time working on a story that is not on the right side of the board? Are we aware that we will increase our inventory by doing that?
Make problems visible
If we want to work with a low inventory, we need to resolve issues as quickly as possible. Blocking issues will increase the number of user stories in progress. This is why. If we can't work on a user story because there is an issue that blocks us, we have two choices: stay idle, or choose another task to work on. Staying idle is not very efficient. Starting to work on another user story on the board is OK, but it's not optimal. The optimal task to work on is a task on the very last uncompleted user story. If an issue blocks me from working on my optimal task, then I need someone who can resolve that issue. My job here is to make it explicitly visible that there is an issue that blocks me. Resolving the issue is a task. A very important task. Blocked user stories need priority If there is a blocking issue on any of the stories, our next task should be to resolve that issue.
How to put it into practice?
We said at the beginning of this article that we will consider this article valuable if our readers try to apply this method. Now it's time to summarize the step-by-step guide on implementing the new workflow.
- List all tasks you are about to work on in the near future.
- Identify the outcome this work contributes to. Try to draw up the value, and name the person who will benefit from this value. Draw up how the outcome will create a value or benefit for that person. Formulate a user story for each outcome.
- Now assign each task to a user story. If everything goes well, we will see that many of our tasks belongs to the same story.
- Create a board with columns that represent the common statuses of your workflow.
- Now focus on user stories. Put all stories in the appropriate column based on their status. If you have more stories in one column, put the most important one at the top of the column.
- Take the top user story from the last column and perform all tasks needed in order to move it forward. Repeat until the story is completed.
If you're working in a team, then you can perform a daily synchronization meeting where team members can discuss and select upcoming tasks. You can use our Scrum Mate agile management tool to help you succeed with this process.