What We Call Stuff Matters…

In my post ‘Organizational Myopia’ we talked about an increasingly common problem with the language we use. We ‘talk’ quite often like we are delivering a cross-functional end-to-end feature of the overall system, when in reality… we are really only delivering a subset of the solution. We are delivering a ‘feature’ that has to be integrated with other ‘features’ in order to deliver real customer value. Why does this matter? It matters because when we allow ourselves to only care about… only track progress on… only get better at our little slice of the world… we risk investing money and time building ‘features’ that might never get sold to an actual customer. Focusing on end-user value is critical to overall organizational success.

Part of our problem is that the language we use to describe value is ambiguous… it’s open to interpretation. Exactly what is a user story? We can go with the Ron Jefferies definition… a card, a conversation, and a confirmation. What is Ron saying? A user story is a placeholder for a future conversation about the requirement. That conversation is supposed to be with the ‘customer’ and we’ve already discussed that a ‘product owner’ is not necessarily our end ‘customer’. What about Bill Wake and the INVEST model? A story should be independent, negotiable, valuable, estimate-able, small, and testable. This definition is more specific as long as we are clear about what adds value. Valuable to the customer? Maybe… but again… who is the customer?

Back in my project management days… we were blending methodologies all over the place and had to get really specific about the language we used. People were learning and we couldn’t take anything for granted. The default corporate methodology was RUP so we talked a bunch about use cases and I spent a lot of time explaining how to break down requirements in that language. During that time we had the notion of a use case, a use case scenario, and a system level use case. Use cases were an umbrella description… an aggregate maybe… of some number of use case scenarios. Each use case would have a primary success scenario and some number of alternate scenarios. A single success scenario and some number of alternate scenarios were typically the minimal increment of business value.

Our applications were complex and quite often any given use case scenario would touch several significant system components. We might have a use case scenario that hit the mainframe transaction processing engine, the enterprise data warehouse, a statement processing engine, a set of web-services, a message bus, and a java based customizable front-end. Each component would have a series of system level use cases that expressed the changes that had to be made for each of our components. Whereas the ‘actor’ for the use case or use case scenario was likely an end-user, the ‘actor’ for the system level use case was likely another system. It was only by building out a number of system level use cases that I would have a scenario, and only some number of scenarios before I had a ‘feature’ that was relevant to an end-user.

Given this as our backdrop… where does a user story live? Is a user story a use case? How about a use case scenario? Could it be a system level use case? I think that in practice most folks would agree that a top level use case is too big for a user story. A top level use case is more like an epic or a feature group. I tend to think of a user story more like a use case scenario. There is a primary scenario, and some number of alternate scenarios, that each individually provide some capability to an end-user of the system. We can prioritize these items, decide what is minimally marketable (how much error handling for example) and be potentially shippable when we are done. Sound like user stories to me. Lately though… and this is the nut of the discussion… I’ve talked with lots of teams that are using the idea of a system level use case as the definition of a user story.

System level use cases ARE an increment of working software. They do have ‘value’ in the sense that they are meaningful to the overall system. They are potentially shippable. The problem is that your customer doesn’t care about them. Another problem is that a team’s velocity delivering these system level use cases is not in any way related to your ability to deliver an end-to-end use case scenario. So… here we have the language problem. If my backlog is filled with system level use cases… but I talk about these use cases as if I were delivering a use case scenario… and measure my performance like I am delivering a use case scenario…then I am only pretending that I am delivering value and my team based metrics are pretty much crap. Many, many teams are starving their organizations… not delivering real value to the business… but think they are doing great agile.

That is a problem.

So… a few posts ago… when we were talking about program level Kanban, project level Kanban, and team level Kanban… this is what we were talking about. We might have any number program level use case… small projects moving its way through the system. These use cases are broken down into any number of use case scenarios and then ultimately system level use cases [that are assigned to teams]. The teams are responsible to deliver the increment of software… the enterprise is responsible for prioritizing that work, planning that work, sequencing that work, and making sure that the work comes together into some sort of aggregated deliverable. If the work of the team is not ever aggregated… in a systematic, disciplined way… we run the risk of having great team velocity and really poor organizational velocity. We need both.

The main takeaway here is that language matters. What we call stuff matters. Thinking about the entire enterprise like and end-to-end system matters. When we allow organizational myopia… when we bend the words to make things work… when we play games with language, we are going to have problems. You need to know what these words mean for your organization… how all of this works together… and what it takes to ensure we are driving real value for the business.