Loading ...
Sorry, an error occurred while loading the content.

Re: [agile-usability] Valuing stories

Expand Messages
  • William Pietri
    Great reply, Hugh. A few thoughts: ... I don t think either of those is necessarily the case in teams that are running well. I m not opposed to doing tasks,
    Message 1 of 53 , Sep 7 7:32 PM
    • 0 Attachment
      Great reply, Hugh. A few thoughts:

      Hugh Beyer wrote:
      > William: I encourage people not to account for all those other tasks...
      > 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 don't think either of those is necessarily the case in teams that are
      running well.

      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
      velocity swings.

      William
    • Adrian Howard
      ... I think that they re probably an orthogonal dimensions myself. I ve met people who make very good decisions about the design of the code/ ux - but are not
      Message 53 of 53 , Sep 11 5:35 AM
      • 0 Attachment
        On 6 Sep 2009, at 21:27, Hassan Schroeder wrote:

        > On Sat, Sep 5, 2009 at 8:31 PM, William Pietri<william@...>
        > wrote:
        >
        >> .... In fact, teams are doing design all the time. The choice
        >> isn't between designing and not designing; it's between designing
        >> well
        >> and designing poorly.
        >
        > Or between designing consciously and designing unconsciously,
        > the latter being fairly close to "not designing" :-)


        I think that they're probably an orthogonal dimensions myself. I've
        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
        very well.

        This can be problematical since their decisions can sound arbitrary to
        others - even when they're really good decisions.

        Cheers,

        Adrian

        --
        http://quietstars.com - twitter.com/adrianh - delicious.com/adrianh
      Your message has been successfully submitted and would be delivered to recipients shortly.