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.
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 , I want so that . You can learn more on user stories here: https://www.mountaingoatsoftware.com/agile/user-stories User stories help us focus on the outcome. Have a look at an example, let's say this article. It'd be easy to say that our goal is simple: to write this article. But, we want something better. Let's think about it a little, how could we address the outcome we want to deliver. How will this article create value? The value of this article will only be realized if readers understand and try this method in practice. So, let's write down our user story.
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 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.
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.
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.
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.
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.
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.
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:
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.
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.
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?
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.
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.
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.
No credit card required