I have received many requests to assist with Agile training and deployment. I am humbled by your interest and, being a huge proponent of Agile, want to help any way I can by providing consulting where I am able to.
January 20, 2010Technical stories - are they included on the backlog?
If you're not already a member of the Scrum development group on Yahoo, you really should join. There's a fortune of information changing hands and you can learn so much from the interactions. Just recently there was a huge debate on the topic of technical stories.
The underlying question the team debated was should technical stories appear on the backlog. If they are on the backlog, it means the technical stories are to be prioritized by the PO. This may not be such a good idea considering that PO's are generally going to be biased towards prioritizing features and functionality over technical stories. Examples given were "Installing Cruise Control", upgrading DB from MySQL to Oracle, Setting up VMWare etc. Most thought leaders on the forum argued that technical stories should not appear on the backlog, overwhelmingly so in fact. But some rightfully point out that all work requiring development resources should appear on the backlog.
"The Product Backlog represents everything necessary to develop and launch a successful product. It is a list of all features, functions, technologies, enhancements, and bug fixes that constitute the changes that will be made to the product for future releases."
"The Sprint Backlog consists of the tasks the Team performs to turn Product Backlog items into a “done” increment. Many are developed during the Sprint Planning Meeting. It is all of the work that the Team identifies as necessary to meet the Sprint goal."
So what's the right answer?
Well, my answer is it depends and it depends on the context. For example, if your definition of done includes unit tests, automated tests etc then these work items don't need to be specific items on a backlog. This is stuff that gets done by the development team and there is no negotiation. Estimates need to include the time required to complete all of these elements of the definition of done.
What about the following story, one of the members asked "As a development team member, I want the existing unit tests to run under CruiseControl, so that I know if anything breaks". Well this is a perfectly written story but the story really has no ultimate value for the end user at least not directly. In this particular case I'd suggest the following:
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." Now Ron is a really smart guy and has ton's of experience and it's hard to argue against his opinions or any of the other smart folks on that forum.
I suggest you decide how to handle this as a team and do what you think is best. I will state however that the XP folks appear to be the most progressive and forging new ground in agile efficiencies and techniques.
Your agile buddy Jack
I totally agree with the post and Ron. Not merely due to the sheer stature of the guru's experience but by the nature of the "story" that should go into the product backlog.
Afterall unless you are developing some sort of "TECHNOLOGY TOOL or PRODUCT" for use by the software community -"Testing through cruise control", "Run a Virtual instance of Ubuntu 9 on Windows XP sp:2A", "Build with maven using Ant plug-in", etc. should not list on your product backlog. The types of use-cases(er, user stories I mean) where these might be acceptable on the product backlog, is building some sort of eclipse-like IDE plugins/tools where these are be the ACTUAL "features" needed by the plug-in. Then probably they may get into the product backlog...little reason otherwise!
Sharing a little experience; we executed a project for "tracking" software licenses and the PO gave us such requirement stories as "Get the software installed/removed/modified remotely","Load balance user requests for shared connections", "Create configurable deployment scripts" etc. but on closer examination some of these could be isolated and reworded into more "Non-technical" stories, while others outright were more of tasks from the sprint backlog - not actually stories.
After some deliberation, a larger part of the Product Backlog was re-written with the auditors and finance people in mind who would actually use the software to track licenses and the administrators who would enforce norms - unfortunately the PO was not very articulate about the end-users need, which was eventually rectified. Bottom line - "user stories" are "USER's stories" not "Technical skills/tasks". What are your views?
Posted by: Anirban Pal | 07/26/2010 at 07:53 AM
Unless you are developing some sort of tech tool of product for use by the software community -"Testing through cruise control", "Run a Virtual instance of Ubuntu 9 on Windows XP sp:2A", "Build with maven using Ant plug-in", etc. should not list on your product backlog.
Posted by: Rapidshare full | 08/23/2010 at 12:08 PM
Thanks for your comments folks, much appreciated. I don't disagree with what's been said!
Jack
Posted by: Jack Milunsky | 08/23/2010 at 07:16 PM
Jack,
How would you go about stories which are very simple and "atomic" from the end user's point of view, but are really complex technically - to the point they do not fit a single sprint.
If we split such stories into something smaller, those smaller chunks would not have any value for the end user - so they do not belong in the product backlog, right?
Posted by: Dmytro Lapshyn | 08/30/2010 at 06:43 AM
Jack,
How would you go about stories which are very simple and "atomic" from the end user's point of view, but are really complex technically - to the point they do not fit a single sprint.
If we split such stories into something smaller, those smaller chunks would not have any value for the end user - so they do not belong in the product backlog, right?
Posted by: Dmytro Lapshyn | 08/30/2010 at 06:43 AM
Jack,
How would you go about stories which are very simple and "atomic" from the end user's point of view, but are really complex technically - to the point they do not fit a single sprint.
If we split such stories into something smaller, those smaller chunks would not have any value for the end user - so they do not belong in the product backlog, right?
Posted by: Dmytro Lapshyn | 08/30/2010 at 06:43 AM
Jack,
How would you go about stories which are very simple and "atomic" from the end user's point of view, but are really complex technically - to the point they do not fit a single sprint.
If we split such stories into something smaller, those smaller chunks would not have any value for the end user - so they do not belong in the product backlog, right?
Posted by: Dmytro Lapshyn | 08/30/2010 at 06:43 AM
Jack,
How would you go about stories which are very simple and "atomic" from the end user's point of view, but are really complex technically - to the point they do not fit a single sprint.
If we split such stories into something smaller, those smaller chunks would not have any value for the end user - so they do not belong in the product backlog, right?
Posted by: Dmytro Lapshyn | 08/30/2010 at 06:43 AM
Jack,
How would you go about stories which are very simple and "atomic" from the end user's point of view, but are really complex technically - to the point they do not fit a single sprint.
If we split such stories into something smaller, those smaller chunks would not have any value for the end user - so they do not belong in the product backlog, right?
Posted by: Dmytro Lapshyn | 08/30/2010 at 06:43 AM
Jack,
How would you go about stories which are very simple and "atomic" from the end user's point of view, but are really complex technically - to the point they do not fit a single sprint.
If we split such stories into something smaller, those smaller chunks would not have any value for the end user - so they do not belong in the product backlog, right?
Posted by: Dmytro Lapshyn | 08/30/2010 at 06:43 AM
Jack,
How would you go about stories which are very simple and "atomic" from the end user's point of view, but are really complex technically - to the point they do not fit a single sprint.
If we split such stories into something smaller, those smaller chunks would not have any value for the end user - so they do not belong in the product backlog, right?
Posted by: Dmytro Lapshyn | 08/30/2010 at 06:43 AM