Technical Tasks in the Product Backlog
- Hi All,
I'm a "Generic Agile" Coach with an XP slant. I often come across Agile teams who place tecnical tasks in their backlog. Many of these teams call these technical tasks "User Stories". These tasks cover a whole range of stuff, such as re-factoring, technical investigations, non-functional requirements, release preperation, bug fixes, etc.
Now I haven't got my Schwaber and Beedle book to hand, but I remember Scrum being pretty loose about what qualifies as something that can go on the backlog, hence why I'm asking this question here.
Should anything other then pure user stories appear on a Scrum backlog, and should these tasks be prioritised along side user stories by the product owner?
Where I've seen this approach applied, invariably the product owner prioritises new features over technical tasks, leading to an inadvertant build up of technical debt.
As anyone else seen this, and does anyone have a solution?
XP, the way I was taught, solves this problem by keeping technical tasks within the remit of the team. The team gets to decide what technical tasks should be performed each sprint, leaving their remaining velocity to be assigned to user stories prioritised by the customer.
This makes more sense to me, since it addresses the approriate balance of responsibilities between developers and customers. Developers should have technical responsibility, whilst the customer has feature responsibility.
I don't think Scrum sees it this way. Is this just an historcal accident (XP came after Scrum and hence had the benefit of hindsight), or is there a good reason for the Scrum stance?
Many thanks in advance,
- Hello, Kathleen. On Friday, July 1, 2011, at 9:47:13 AM, you
> In some posts, there seems to be a focus on doing things 'by theYes, I do agree. And at the same time one does need to start
> book', rather than exploring the possibilities of other concepts
> or techniques that might be useful. It implies that the method is
> the 'one true way' of doing things, and that you don't need to
> learn anything else to be successful. Unfortunately, reality is
> way too messy for that to be true.
> To get really good at something, you need to go beyond mastery of
> a given method (or words of a specific master). You need to learn
> the underlying theory and principles (like what was mentioned
> before), then integrate the ideas and processes in new ways to
> deal with your current situation.
/somewhere/, inside the "safe region" for learning before you die.
Scrum purports to define part of the safe region.
> Creating new concepts should be encouraged. We should all beAgile got started based on the combined experience of a large number
> challenging the status quo and pushing for better ways to do
> things. Isn't that how agile got started? Why stop now?
of people who had observed a large number of teams for a large
number of years. It is possible that those people knew rather a lot.
It is also possible that teams starting out to do this stuff are not
yet qualified to make decisions about what to do and what not to do.
Show me the features!