49466Re: Keeping cross-cutting tasks visible (without technical stories)
- Dec 1, 2010Personally, 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 firstname.lastname@example.org, 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)?
> Paul Tevis
- << Previous post in topic Next post in topic >>