My employer has been moving from traditional waterfall projects to a modified version of agile. Work is broken into stories, which are estimated and sequenced into two-week long iterations. Each iteration includes points for building, testing, and accepting features.

Stories are focused on testable business features. There is no way to plan and account for cross cutting concerns such as design, architecture, infrastructure, or (ironically) project management.

Should agile teams explicitly include stories or tasks for these cross-cutting concerns? How does your team handle tasks that never go away? Are they "off book"?

  • 1
    You may want to have a look at this question for an example of handling cross-cutting concern such as architecture. Aug 15, 2014 at 13:03
  • Necessary, but not sufficient.
    – duffymo
    Aug 15, 2014 at 13:18
  • It doesn't matter. The team should be including ALL work to Done in their point sizing. As a manager all you should care about is points per iteration. The rest is up to the team. Aug 15, 2014 at 15:43

3 Answers 3


I've seen two basic approaches:

  1. Add recurring, timeboxed tasks to each sprint for these kinds of issues. This increases the visibility of the tasks and allows checking whether a specific step or task is Done. The downside is more overhead cloning or recreating these tasks from sprint to sprint.

  2. Just set aside a collective timebox for these tasks each sprint, reducing the available time for implementing stories in the sprint accordingly. This is simpler to manage, but makes it more difficult to manage the individual tasks included in the box.


Yes create stories for design, architecture, infrastructure and project management.

You may wish to create an additional board for them, at least initially.

Ultimately they involve people doing work so as they get developed you should be able to either assign people to them or move them into a team's project board.

One thing we do for more intangible stories sometimes is creating spikjes that are time-bound, e.g. "2 days" to do such tasks.


TL:DR; Stories for systems architecture, emergent design through refactoring and code deduplication.

This is what we do at my work:

  • Systems architecture and infrastructure is treated as a story (or multiple stories), in our parlance it would be a research card. The research when done answers a question and usually leads to more well defined stories or cards.
  • Code design is dealt with differently. We practice emergent design through constant refactoring and code deduplication that is always a part of every programming task we do.

An Aside:

As you may well know refactoring design can be very difficult, especially with an established code base. One of the biggest mitigating factors for us that makes iterative design even possible is doing Acceptance Test Driven Development. We create a test suite that defines and tests our systems behavior. This has allowed us on occasion to completely rip out entire subsystems, reimplement them and still be confident that everything works. We usually try and do this iteratively and as part of providing customer value. However, there are exceptions to the rule and when those arise (rarely) we have spent a few days solely on reworking some part of the design. BUT, that is okay because they are rare occurrences and our process allows for exceptions.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.