Thanks Niall. This is an interesting question. My thinking here is that the outcome you are trying to achieve may not be measurable or easily measurable in the short-term. So I wouldn't not tie that directly to this process flow exactly but we could try it.
If using Kanban style dev where there is a continuous flow this might make for an interesting exercise to add a couple columns, e.g. Outcome Achieved, Outcome Not Achieved. Then we can see how work done by the team, over time accumulates in the outcome columns. A lot of work ending up in Outcome Not Achieved would cause the whole team to start thinking about how they can fix this.
In Scrum, or other Sprint based approach, this might be difficult to visualize as such because once a Sprint is over, people rarely go back and look at the old Sprints. So if we are tracking outcomes there it might not work in the teams normal workflow.
It's been my experience that tracking outcomes often falls outside the tools because they don't support it well. This is something worth spending more time figuring out. By keeping it outside the standard tools and process, we tend to only measure outcomes on bigger initiatives because tracking it for everything is hard to do manually.
Bottom line -- I don't have a good, best practice answer but will explore this more.
Great post, Sean.
In the updated version, what are the criteria you would apply to the 'Done' column at the end?
Would you consider outcome-oriented metrics?
Let's say, for example, a feature was intended to improve the activation rate by X%.
Would the team track this here or elsewhere to see if the feature actually delivered the intended result?
Thanks Niall. This is an interesting question. My thinking here is that the outcome you are trying to achieve may not be measurable or easily measurable in the short-term. So I wouldn't not tie that directly to this process flow exactly but we could try it.
If using Kanban style dev where there is a continuous flow this might make for an interesting exercise to add a couple columns, e.g. Outcome Achieved, Outcome Not Achieved. Then we can see how work done by the team, over time accumulates in the outcome columns. A lot of work ending up in Outcome Not Achieved would cause the whole team to start thinking about how they can fix this.
In Scrum, or other Sprint based approach, this might be difficult to visualize as such because once a Sprint is over, people rarely go back and look at the old Sprints. So if we are tracking outcomes there it might not work in the teams normal workflow.
It's been my experience that tracking outcomes often falls outside the tools because they don't support it well. This is something worth spending more time figuring out. By keeping it outside the standard tools and process, we tend to only measure outcomes on bigger initiatives because tracking it for everything is hard to do manually.
Bottom line -- I don't have a good, best practice answer but will explore this more.