Mike is a certified PMP project manager and a certified ScrumMaster. Mike was involved with the creation of the DSDM Agile Project Leader certification, holds this certification at the Foundation, Practitioner, and Examiner levels. Mike was named an honorary member of the DSDM consortium and served on the board of APLN and the Lean Software and Systems Consortium. He currently co-leads the PMI Agile Community of Practice. Mike is a DZone MVB and is not an employee of DZone and has posted 147 posts at DZone. You can read more from them at their website. View Full User Profile
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
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
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
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.
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.