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

49466Re: Keeping cross-cutting tasks visible (without technical stories)

Expand Messages
  • peterskeide
    Dec 1, 2010
      Personally, I don't mind mixing and matching different types of requirement formats if the situation calls for it. User Stories are fine, and often the preferred format, but (imo) sometimes a simple technical requirement can be the right thing. It all depends on context. Some technical issues can easily be baked into a User Story. Some can't. If it feels wrong, it may simply be wrong.

      Perhaps a sprint backlog where the majority of issues are value focused User Stories plus a few technical requirements will work for you? Try it. If it doesn't work, try something else.

      Whatever you do, I think it pays to be open about it when talking with the Product Owner. If your team feels there is a need to work on something with a purely technical focus, explain the situation to the PO. He/she may understand, and allow you to work on it during a Sprint. If the PO doesn't allow this, and you end up having to "hide" some of these issues in unrelated User Stories, it may be a sign of other, more serious problems.

      Granted, if your team does a good job of focusing on quality when implementing User Stories, these types of issues should be rare.

      --- In scrumdevelopment@yahoogroups.com, Paul Tevis <ptevis@...> wrote:
      > The team I'm on right now is about four months into a Scrum
      > transition, and we're finally starting to deal with technical debt
      > reduction and technical practice improvement. One thing that I'm
      > struggling with is how to make the work that we're doing on these
      > visible to the team, while at the same time keeping our focus on
      > delivering customer value (i.e. doing real stories).
      > For example, a while back we set up a minimal Continuous Integration
      > server to make sure we didn't break the build. This was in parallel to
      > the existing system that creates the installers we send to customers,
      > which only built once a day, didn't run any tests, and was not
      > well-understood by any current members of the team. (There had been a
      > lot of turnover on the project prior to our transition.) Now, we'd
      > like to move that functionality to the CI system, to make it easier to
      > maintain, to improve our testing process, and to move closer to
      > Continuous Delivery. We know this will take a non-trivial amount of
      > work, so I'd like to keep it visible, but I don't want to make a
      > technical story for it.
      > Similarly, we recently needed to cut a release branch, which involved
      > updating some scripts, etc. This was a purely technical task, one that
      > the team felt was necessary to maintain a level of quality, but that
      > wasn't connected directly to any single user story.
      > My concerns are (1) as soon as we start tracking non-story tasks we'll
      > lose focus on delivering customer value, and (2) if we don't make
      > these sorts of tasks visible, we won't make progress on them at the
      > rate we need to. What are good patterns you've seen for dealing with
      > technical tasks that aren't directly attached to a story (or that cut
      > across multiple stories)?
      > Thanks,
      > --Paul
      > --
      > Paul Tevis
      > ptevis@...
      > http://paultevis.com
    • Show all 28 messages in this topic