When it comes to focus, I am deeply convinced that you should focus on the right things. That raises the question what the right things would be. In the Lean community there is a saying that we should not focus on outputs, but rather on outcomes. Let’s try to turn this argument around, and wonder how we can focus on outcomes rather than outputs.

Daily Standup Meeting

The main objective int he daily standup meeting – whatever process model you follow – does not lie in the output – the updated sprint backlog in Scrum, the updated Kanban board when using Kanban, or whatever you. The updated board is an output from the discussions that should arise. So, what is the main objective in this meeting?

It’s that the team should coordinate itself in order to provide the best value possible up until the next time we get together. The main objective lies in coordinating the team’s work. The updated board is a result of that, and should be a means to that end.

User Stories

The key value of a user story does not lie in the adherence to some kind of user story template.

As a user
I want business functionality
so that I earn more money.

This would be a user story that is completely adhering to the template. But is it helpful? Or guiding? Well, I don’t think so.

That is, it is focusing on the output, the phrases in the user story, rather then the outcome. As Ron Jeffries put it, a user story consists of three Cs:

• Card
• Conversation
• Confirmation

Ideally the team should spend 90% of their time on the outcome, the second C, conversation. The outcome of user stories lies in the shared understanding. You can generate a shared understanding of a feature to be built in the most efficient way by talking face-to-face about it. That’s the outcome of a user story. Focus on that – not so much on the template.

Acceptance tests

When working with acceptance tests, you can focus on expressing the acceptance criteria quite perfectly in the tool that you picked. That’s focusing on the outputs, rather than the outcomes.

As with user stories, the biggest value of acceptance tests lies in… the discussion. The outcome is a shared understanding of the feature to built, and the constraints that you need to fulfill. The constraints are expressed in some manner using a language of the tool that you picked. But the bigger value comes from the shared understanding.

Also consider that automated regression tests is rather an output from the acceptance tests rather than an outcome. It’s perfectly fine if you throw away your acceptance tests – before or after automating them. The shared understanding is the bigger value.

Planning

When dealing with planning, be it Sprint Planning, Release Planning, or traditional style project planning, the value lies in the planning activity, and reaching consensus about it, rather than the output, the plan. No plan survives the first contact with the enemy. Having a release plan really means that you have a notion of the upcoming release cycle, and guess that based upon your guesses in estimations and your past progress you are able to deliver this piece of functionality. Sounds like too much vagueness for me to be real. The outcome of the planning activity though lies in the shared understanding about what we are going to focus on for the next timeframe. That’s the higher value proposition.

Now what?

Next time you boss asks you to do something, and you have the impression that he’s asking you for a deliverable, ask for the reason for that deliverable. Most of the time there should be both, a consumer behind the deliverable or artifact, and an outcome that is a side-effect of producing that deliverable. Try to understand what’s more crucial for your situation right now, the deliverable, or the outcome. In the long run it will serve you better to understand those forces at play.