When developing technology it’s easy to focus on the tasks, but really one should focus on the outcomes. I’ve found myself saying “Outcomes, not tasks” a lot recently, and in particular helping people do this for user stories in Scrum teams. Here are some of the reasons:

• It helps the team work together. Tasks are more likely to be done by individuals. Outcomes allows the team to work together more effectively to draw out the tasks, distribute them, and then come together to ensure it’s all happened as planned.
• You’re more likely to get the right result quicker. Lots of people think they want tasks done, but really they want certain changes to happen. (E.g. “I can’t see employees on the same screen if they have different pension plans; I want that to change.”) If the team doing the job understands the end goal then they’ll stop when that’s achieved. If the incoming task list was incomplete or underspecified then a task-oriented team won’t realise they’ve not helped achieve the end result; there will be a delay before the truth is discovered and potentially another delay while it’s all explained and rescheduled. An outcome-oriented team is more likely to be correct when they say they’ve done the job.
• It fosters stronger ownership of their work. If the team is given the desired outcome and has to work out the tasks themselves then they are more likely to own the consequences of their actions. If they’re given just the tasks and divorced from the outcome then you can expect less engagement if the consequences of their prescribed actions don’t have the outcome intended.
• It fosters stronger buy-in to the whole project. If team members can see links more clearly between their own work and the bigger picture then they will be more committed to the work as a whole.

Once again: Outcomes, not tasks.