Re: [agile-usability] Valuing stories
- jonathan berger wrote:
> Should we write design stories separately? If so, do they have points?Most of the teams I work with have one system for tracking work:
> How would we measure velocity if a "design-point" is different from a
> "dev-point"? Maybe there should be a separate tracking system? We've
> found the friction caused by integrating two tracking systems results
> in the smaller system (design-tracking) breaking down because it
> ceases to reflect reality.
> So that's what I'm struggling with. I'd love to hear suggestions or
> stories relating to concrete, real-world examples or techniques for
> integrating design into agile planning.
stories. To execute each story, you do just enough work (design,
development, testing, etc) to make it happen responsibly. To plan each
story, you do just enough planning to responsibly prepare for execution.
As far as real-world examples go, I and a colleague looked at a bunch of
teams, from small startups to large companies. We tell their stories and
talk about the practices we saw here:
If you've got further questions on any of those outfits, I'm glad to
- On 6 Sep 2009, at 21:27, Hassan Schroeder wrote:
> On Sat, Sep 5, 2009 at 8:31 PM, William Pietri<william@...>I think that they're probably an orthogonal dimensions myself. I've
>> .... In fact, teams are doing design all the time. The choice
>> isn't between designing and not designing; it's between designing
>> and designing poorly.
> Or between designing consciously and designing unconsciously,
> the latter being fairly close to "not designing" :-)
met people who make very good decisions about the design of the code/
ux - but are not really able to articulate the reasoning behind them
This can be problematical since their decisions can sound arbitrary to
others - even when they're really good decisions.
http://quietstars.com - twitter.com/adrianh - delicious.com/adrianh