> On another point, I think your example
illustrates the difficulty with
> keeping the "whole product" concept
coherent when your only
> representation is story cards and UIs. If you
don't have a physical
> artifact to check, it's easy to overlook
connections across the parts.
Well, I think it's an intrinsically
difficult problem, no matter what
representations you use, especially given
that any single representation
necessarily discards a great deal of
Absolutely, and you're giving us a success case here... I'm not
saying we could have done better, only playing with the
Personally, I like
something as obviously inadequate as the cards.
With a 200-page spec,
people often yield responsibility to the spec. With a
stack of index
cards, it's clear who has the answers: the team.
perhaps I'm using the wrong representations. Let me give you the
details and you can suggest a representation that would have found
problem sooner and at a lower cost.
The feature in question was a very
simple content management system that
controlled the pages of static
content on our site. E.g., who we are,
what we do, the FAQ, our terms and
conditions, and so on. It was
scheduled not for the upcoming release, but
the one after that.
While we were implementing one of the stories
related to payment, a
programmer noticed that we needed more explanatory
text on one of the
UIs to convey the full terms. But it was really more
text than would
fit, and the best thing to do was to give a short message
most users, and link to the terms and conditions for the few
The static content story, though, was
scheduled in the following
release. So we, as a group, spent perhaps ten
minutes talking over
alternatives. Eventually, we split the story in two,
necessary part of it in this release and the fancier features
Total cost of this change was perhaps one person-hour of discussion,
perhaps two minutes updating our artifact. The HTML mockups
ignored; they're only kept fresh when the designer is thinking
about the future or when they're the best way to communicate the
of a feature we're building that week.
would have you used to detect this scheduling error
sooner, and at lower
Our approach to this is through what we call a software
floorplan or User Environment design. It shows all user-visible features and how
they are arranged into coherent screens/windows/pages. When we're planning
releases (haven't used this in an agile project) we do cuts across the floor
plan and run a discussion of whether the cuts are coherent--each delivers
complete, useful function and can be delivered independently. So in
theory, running such a process would have identified the
practice, such a discussion takes a good deal more than an hour. Besides, this
was an additional need discovered during implementation--we might have found it
up front, but might not.
What I'm wondering about is whether maintaining such a "floorplan" could
be useful for keeping design coherence on the user experience side. So in
your case, you would have walked to the floorplan on the wall, which might
have been marked in colors to show what was being delivered in this release
and the next. You'd make your decision, and draw a box to represent your
detailed terms box, in the color for this release. If any other
user-visible features were affected by moving the static content work into this
release, you'd change the color on those. Then you'd split the story
and be done.
Benefit is that the next person who's looking at what's happening in this
release--maybe another team member discovers another change that
depends on some static content work--only has to go glance at the plan to see
what you've done.
Does that seem potentially useful?