Re: [agile-usability] Valuing stories
- Great reply, Hugh. A few thoughts:
Hugh Beyer wrote:
> William: I encourage people not to account for all those other tasks...I don't think either of those is necessarily the case in teams that are
> My default position is that teams should only count things when they
> deliver value to the people we're trying to serve.
> I'm allergic to doing work with no way to account for it. It screws up your velocity in the first place, and work you're not tracking is work you don't care about in the second. I'd rather keep the story as the unit of user value and track tasks to implement the story which may well include non-software tasks.
I'm not opposed to doing tasks, but I discourage teams from focusing on
them or putting much energy in to tracking them. Instead, I encourage
them to focus on frequent delivery of real-world value.
For example, on the most successful teams I coach, they'll do a task
breakdown not long before they start a story, and erase it once the
story is accepted.
Work not directly tied to the execution of stories happens, naturally,
but most of it is driven by planning for stories. Stories need to get
estimated before they can get built, which forces people to think and
learn about exactly what is needed. The backlog needs to be kept full,
which pushes stakeholders to figure out what they're trying to achieve.
Similarly, frequent delivery drives improvements in process, code
quality, and working relationships.
> This runs up against another rule I like, which is: If you don't have a story for it, and no test is broken, don't do it. Which means you only refactor when you're touching the code anyway, and then you can estimate the story to include refactoring. This guards against the tendency I've seen to make the code ever-prettier without actually advancing user value.I see this as a balance that can go wrong in both directions. Some
developers definitely spend too much time on gold-plating things that
only developers care about. But other teams underinvest in keeping
things clean, also pushing productivity below the optimum.
Some teams like to solve this by introducing explicit refactoring
stories. Like you, I think it's better for the team to focus on
delivering real value while incorporating any necessary cleanup as part
of the story. But I think it's also better to allow developers a
consistent, modest amount of time for cleaning up whatever they think
needs cleaning. I often call it the black budget.
My reasoning is that even for teams working as cleanly as possible, debt
appears over time. Not because the code gets worse, but because
standards get higher through better understanding and increased skill.
Telling developers they aren't allowed to correct problems they think
important strikes me as dangerous. If you really don't trust their
judgment, that can be a necessary evil. But I think it's better to just
to put some limits on that, so that they can develop the necessary
judgment in a way that doesn't harm the project and doesn't cause
- 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