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.
Technical 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
I like your post very much. The way of presentation is extraordinary one. Because, the layman also easy to understand.
Posted by: Software Testing | 10/12/2010 at 10:07 PM
@Dmytro
A lot of folks argue about not being able to break up stories small enough. What you have to do is get creative about layering a thin slice of functionality on top of the architecture bit. However if it's absolutely not possible, I would just treat this as a spike - there's quite a bit of literature on spikes just google it. Spikes still get time boxed and since architecture is a necessity for the ultimate functionality that you will deliver I would still count that as adding value personally and I would count towards my velocity. But try very hard to build the architecture bit by bit layer by layer
Hope this answers your question.
Jack
Posted by: jack | 10/29/2010 at 09:54 AM
This is definitely a blog that people need to get behind. The problem is, no one wants to do a great deal of reading and not have something else to stimulate the mind.
Posted by: biletul zilei | 11/27/2010 at 01:01 AM
Thanks
Posted by: Jack Milunsky | 11/29/2010 at 06:15 PM
That was the most techie blog I ever read. At first read I didn't get a thing so had to go through again. Working on Windows XP was an interesting experience, I use Vista now but still prefer working on XP as well.
Posted by: Dow jones history | 01/10/2011 at 10:27 AM
Thanks for your comments folks, much appreciated. I will agree with what's been said!.The way of presentation is extraordinary one. Because, the layman also easy to understand.
Posted by: ecommerce developers | 01/24/2011 at 03:16 AM
totally agree with the post
you are so smart, I admire you
Posted by: miami web services | 03/20/2011 at 05:38 PM
Nice work on putting together a very interesting post. Fabulous ideas and very helpful information. Well thought out and well written.
Posted by: SY0-201 | 05/11/2011 at 05:07 AM
I think your articles are so interesting that I need more information, go is berkaya and I will always support you.
Posted by: Testking 000-106 | 05/27/2011 at 04:15 AM
I want to get more time to see it . I think if you write more original blogs like this , Thanks for sharing .
Posted by: logo design | 05/30/2011 at 11:10 PM
Such a nice stuff always fascinate me.Your approach is very creative.Keep going.
Posted by: Testking 000-533 | 06/10/2011 at 08:49 PM
For businesses it needs to stay updated by using new software solutions. Some apps could be developed by outsourced company that provides Microsoft .Net development for business companies.
Posted by: Outsource software development | 08/12/2011 at 05:09 AM
quite interesting discussion, quite interesting approach by author
Posted by: best man speeches | 08/24/2011 at 05:28 AM
agile algorithm is the best. mostly of android phones right now have agile apps.
Posted by: track cell phone location | 09/27/2011 at 07:47 PM