Here I am in the process of scoping and estimating a relatively small new software development project. I have been through the user stories suggested by the customer and placed tasks against each, with an estimate and some brief notes on how the task will be accomplished. There are acceptance criteria. All ought to be good with the world.

enter image description here

When looking at the work I'd planned, I realised there was something missing. There is going to be initial outlay in simply setting up things into which we can bolt functionality. Things that belong to all user stories, not one particular user story.

For example, part of this application is a service that parses XML. From the user's point of view there are specific stories where different things will need to be done depending on the content of the XML. Actually writing an XML parser - the bits that look for a file, read it and pull out the relevant data before deciding what to do with the contents - is part of all those stories. As is wrapping it in a windows service with an installer etc. It is a developer-centric task with no direct relevance to a user.

Another relevant example from this particular application is taking and rewriting a block of poor legacy code which is useful to the functions of this app. Again, this has no immediate outcomes for the user but it's necessary work. Where does the planning and execution of this work "live" in a project plan focused on user stories?

I have seen people solve this by writing user stories "As a developer, I want to ..." but as has been discussed elsewhere this isn't a user story. It's a developer one.

I am seeking a concrete answer to this, to help me (and others) planning projects using strict management frameworks like TFS online. These do not tend to have the function to make "stakeholder stories" or other vague meta-solutions mentioned in the answers to How does a Scrum team account for infrastructure tasks in the planning meeting?

  • 2
    If I tell you that a computer or a service can also be treated like a "user," does that alter your analysis? Jan 19, 2017 at 17:25
  • 3
  • 1
    @mmathis I saw that question, and it's similar and relevant. However, none of the answers actually answer this question. Especially when you factor in a focus on how to do it within existing frameworks like TFS.
    – Bob Tway
    Jan 19, 2017 at 17:27
  • @RobertHarvey partially, yes. That would cover the service in this instance, but not the legacy code. I can think of other situations where that approach might not cover the requirements. I'd also be interested to know how widely accepted that is: seems like a semantic change to get around the "as a developer" problem.
    – Bob Tway
    Jan 19, 2017 at 17:28
  • 2
    You can cheat at have system users, and iteration0, or you cut the cake differently. First feature gives some user functionality and the infrastructure that is needed to get it to work. Then feature 2 that consequently brings up some more infrastructure, this way you don't wast time setting up infrastructure that you do not need. If you are now screaming but that means I need to re-plan, then you are not doing agile. Jan 19, 2017 at 22:33

3 Answers 3


I like the other answers that say to put as much "tooling" code as you can into Iteration 0. However, sometimes, these kinds of tools come up after the project has already started. Perhaps in Iteration 3 you realize you need a generalized XML parser widget to be used on various stories going forward.

In that case, the first User Story that relies on these internal architectural pieces is the one that they belong to. If you are about to work on Story #345, and it will depend on your XML parser before it can be counted as 'done', then your re-usable parser will be attached as work for that story to be completed.

My team has used the above approach and it seemed to work fine for us.

  • I was going to answer similarly to this one. If a story needs something, it's a part of that story. Some stories might just get the benefit of coming after another story that built out the infrastructure. However, you need to keep all those stories that need it requiring it just in case stories get re-prioritized. You can't be sure what the first one will be.
    – Jay S
    Jan 20, 2017 at 12:51
  • 1
    +1 This touches on a great point. Whether it is called iteration 0, 1 or whatever is a bagatelle. All but the most unreasonable or uninformed understand that some groundwork is required. If you paint, you prep the walls, if you cook, you chop, if you're a musician, you practice.
    – Robbie Dee
    Jan 20, 2017 at 12:51

If it's infrastructure it's typically put into Iteration Zero. What's Iteration Zero? It's typically the time between kickoff and planning before actual iterations start.

An example, say we need a new web service. So, I need to create the project, set up continuous integration, set up a source control repository, set up build script and automated deployment, etc. Users doesn't really care about these, but we need these regardless.

So, that work would be done in iteration 0. By the time iteration 1 started, there would already be a new project shell that would compile, have an automated build script, and would deploy. Now, none of the user functionality would be there, but it's ready to go.

I would still track and plan this work as part of iteration 0 work.

The refactoring sounds like a technical story which can go in any iteration.

  • 4
    +1 because we use this as well, but in reality Interation Zero is the new Iteration One. It's just an iteration that the business stakeholder doesn't really care about, but is necessary to get to the things the stakeholder cares about. Jan 19, 2017 at 17:53
  • You can have a bona fide iteration 0 but that isn't to say you can't start delivering value from day 1. You don't need a build server, automated deployment and source code repository to start cutting code - this can happen later (or even in parallel).
    – Robbie Dee
    Jan 20, 2017 at 12:55

Depends on the infrastructure.

If the infrastructure is very significant, or has to adhere to complicated compliance regulations, then you may have a separate infrastructure team, who may have a schedule of their own. It might be Agile, it might be waterfall. In this case, the construction of the infrastructure would be managed in your project as an external dependency.

If the infrastructure is going to be managed by your team, and set up only once, you can use the iteration 0 technique that Jon describes.

If setup of the infrastructure will take several iterations (e.g. maybe you set up your build server now but QA and preprod servers will be built a little later) then their buildout can be managed as nonfunctional PBIs. Functional PBIs may have certain dependencies on these, which you can codify in TFS using the "predecessor" link.

And of course you can mix and match all of the above. For example, you can't do much without a continuous build server, so you could put that in iteration 0. Meanwhile your preprod servers might be defined as tasks for iterations 2 and 3, and they may have external dependencies on your DBA team (who aren't Agile) who will be allocating you DB instances in your data center. Or maybe you have to wait for SSL certs to be issued for certain features; they can go in iteration 4, and any functional items that rely on those certs should be linked to them with a predecessor/successor relationship.

In all cases, remember:

  1. Always define clear acceptance criteria. Hardware guys have an annoying tendency to stand up a server and call it done when it has not been validated at all.
  2. During your team's iteration kickoff, the team will need to examine the dependencies and their availability before committing to any PBI or work item.
  • Hardware guys have an annoying tendency to stand up a server and call it done when it has not been validated at all Good point - hence the recent prevalence of DevOps.
    – Robbie Dee
    Jan 20, 2017 at 12:58

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.