In agile, how are basic infrastructure tasks at the start of a project planned and allocated using strict management frameworks like TFS online?

Question

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.

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.