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?
Best Answer
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.