- This type of story definitely doesn't belong on the product backlog but would be a perfect task that could exist on the Sprint backlog assuming you're tracking tasks. I am still in the Scrum camp on task breakdown as opposed to the XP folks who prefer to work just at the story level. If you're doing task level breakdown during the sprint planning meeting then this type of Story or work could exist on the Sprint Backlog as a task and the time associated with doing this can be tracked on the burndown. Most XP folks will say this is just micro-managing all over again.
- To quote Ron Jefferies: "Technical stories have been found to be an inferior idea by many practitioners who have tried both ways. I don't know of a single one who would go back.
- I suggest you decide how to handle this as a team and do what you (the team) think is best. I will state however that the XP folks appear to be the most progressive in forging new ground in agile efficiencies and techniques so watch what they say carefully and even consider what they say.
- March 28, 2010 by Maritza van den Heuvel
- I'm the PO on a fairly complex enterprise-level server-client authoring tool in the e-learning industry. In our team, technical stories are kept on the backlog. We believe it's important that they should be, since it gives them visibility beyond just the technical team. Very often, if business is not aware of pressing technology needs, there will be no support to do them.
- By having the stories on the backlog, I am making stakeholders and non-technical people aware that they have to pay the piper. Fast-delivered features are not free - there is always technical debt to pay off. And often, by prioritizing a particular technical story, it enables us to pre-empt support issues. And support issues can derail sprints, so the less of those we have to deal with, the better. The value in actually tackling the technical stories transparently, is really that we are protecting our other sprint goals and over time continuing to build in quality in the product.
- But I don't prioritize technical stories on my own. I do this in conjunction with the Scrum Master and one or more technical leads to ensure that I get the complete picture.
Ron Jeffries
Extreme programming installed (By Ron Jeffries, Ann Anderson, Chet Hendrickson)
Don't break the circle - customers write cards, developers do them. Where possible - and it usually is - you should solve this by relating the technical task back to a real customer need, and breaking it down into iteration-size bites.
Carlo Kruger
http://www.slideshare.net/ironicbuddha/writing-effective-user-stories-2688143
Technical Stories • Adding CI, optimising DB, upgrade to latest Oracle, etc. • Consider trying to write a user story so that you are forced to define the business value • No user facing functionality, e.g. Rating engine consumes some output • Consider writing as a user story with the engine as the user • e.g: As the rating engine, I want well formed CDR’s so that I can minimise error logging • Don’t hurt yourself trying to force it; sometimes it’s OK not to use the format • Be careful that these aren’t tasks that have been elevated to stories...
