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?