A question I get frequently is what to do with tasks that do not belong to a particular user story or product backlog item. Common examples I’m asked about include tasks like “update the build server to use the latest version of FitNesse.” Fixing bugs from prior iterations are another common example. I’ve sometimes heard of these tasks that don’t belong to a particular product backlog item or user story referred to as “storyless tasks.”
If you’ve been to one of my classes, heard me speak at a conference, or just poked around my website you very likely know that I have a strong preference for task boards whenever possible. Usually this means whenever a team is collocated or a few special distributed teams who want to do it. A taskboard will look something like this:
To answer the questions about storyless tasks, I want to answer in the context of using a task board. But the essentials of my answer will remain the same even if you are using a tool.
Most teams find it useful to include two additional rows on their task boards:
- Miscellaneous
- Bugs
Each other row on those boards represents a user story and the cards are the tasks to implement the story. The Miscellaneous and Bugs rows are essentially the storyless tasks. The Miscellaneous row holds things like “update the build server.”
I do not normally recommend that a team estimate these items in story points such that they would earn any points toward velocity by completing these tasks. Tasks in the Miscellaneous row are usually tasks that enable the team to perform the other work (or to perform it better or faster). It is reasonably safe that over the long-term any story points you’d consider assigning here will average out. This is yet another reason why I always stress that velocity is a useful long-term predictor rather than a predictor of the short-term such as what a team may complete in exactly the next iteration.
I often use a Bugs row on the task board for bugs that are either:
- discovered during the iteration but unrelated to the stories of the current iteration (bugs related to stories already on the board go into the To Do column of the story’s row)
- planned at the start of the iteration to be done during the iteration
If the bugs were planned into the iteration at its start, often a team does put a story point estimate on those bugs. Usually the bugs are estimated together–that is, “if we fix these 6 bugs we’ll get two story points.” Lots of teams with large defect backlogs plan to do something like bring in 5 points of bugs each iteration. So they estimate those a bit “backwards.” Rather than grab a stack of bugs and ask, “how many points do these 8 bugs represent in total” they keep adding bugs into the iteration until they feel they’ve brought in the desired number of points worth of bugs.
Tags: defect management, taskboard
This is a common question indeed, and your suggestion is one way to go. Another approache that I have used in the past is simply to consider these tasks as belonging to the first story where they could make any sense.
To use your examples, if we need to “update the build server to use the latest version of FitNesse†we would consider this something that is needed for the first story that is likely to involve the build server, that is; any story that involves coding. The reasoning here is that keeping the build server up to date is something we have established as being a good thing for our project and thus we fix that as soon as we feel it’s appropriate, just like we would do a refactoring when we decide we need to without creating a “Refactoringsâ€-story, whether the refactoring concerns a new story or was originally developed in a past story.
This could also be anchored in the definition of done using terms such as “Make sure development tools are up to dateâ€. We simply accept that our definition of done causes us to add various tasks to stories from time to time.
Same goes for bugs (in case they’re not known in planning, in which case I do like you describe). If bugs are discovered in mid-Sprint we do our best to fix them in the current Sprint, since our definition of done reminds us to try to be as “done†as we can.
This of course affects a team’s velocity, but like you said, velocity is a long term predictor, and if velocity is hurting because of bugs and/or unanticipated tasks, that is probably an interesting sign and something to keep an eye on. Can we reduce the bugs we leave behind? Can we streamline our development tools?
Anyhow, thanks for bringing the subject up, it’s a common question indeed and it’s interesting to see how different teams deal with it.
Hi PÃ¥l–
Yes, what I’m describing is just one of a few good possible solutions. I like your approach when there’s a logical place to put the “storyless task.” Sometimes the task is so fundamental that it doesn’t fit with one product backlog item any more than another–for example, “upgrade all developers desktops to Vista.” (Hmm, from what I hear as a Mac user, that may not be a good idea, though
)
When there’s a reasonable place to put a task, put it there. What I’m suggesting above is that many teams have just miscellaneous work that needs to get done that benefits from being visible in the sprint backlog. Things like “Meet with Steve to go over his needs for the next version” or “meet with facilities about new cubicle arrangement” are things that end up in the Miscellaneous row of a task board.
Nice write up. One thing I have to disagree with is getting story point credit for working on bugs. I’ve always been opposed to this. By doing this, you are essentially giving a team credit *twice* for messing something up the first time. By “team” I don’t just mean the developers, because the problem could have been with a product manager, or a technical writer, or a professional services team.
I consider “zero bugs” a criteria for being done. With this view, open bugs equate to unfinished stories. So if the team said they were done with Story X and delivered it to the customer, then found a bug, they must accept that they were not really done. To put the Story X bug on a backlog and continue developing Story Y or Z is a sin. The team should stop the line, fix the bug without getting credit for it, and make note of how it slipped past them and how they can avoid that mistake in the future.
If you have a large backlog of bugs, and spend an iteration fixing bugs, your velocity should be zero for that iteration since you’ve already (unduly) received credit for the stories in which you wrote the bugs.
If you look at story points as currency — which they essentially are since product owners shop with them every iteration — introducing “bug points” into your long term estimates inflates and devalues the story point currency.
Hi Javid–
Good catch. I wasn’t clear in the initial post. I am referring to bugs that have been around from before a team started agile or even that are found in old-but-agile code. Let’s consider each separately:
Legacy Bugs: I have teams estimate these with story point and claim velocity credit on them because this better reflects the fact that team is spending effort on the bugs. And that effort could be spent on new features instead. A real example of a team I worked with: The team had an average velocity of 9 points worth of new features and 2 points worth of fixing old bugs. They could have earned 11 points by working on new features only but the team and product owner agreed they should dig out of the hole of old, important bugs. When they eventually did, their velocity remained 11 but the 11 points were then targeted solely at new features. To not give them velocity credit in this case would have shown an increase in the productivity of the team, which wasn’t the case. We can’t even argue that they were then delivering more “business value” because the business had prioritized “do 2 points of bugfixing each sprint” as most important.
Bugs In Old-But-Agile Code: First, let’s consider bugs in code from last sprint: The team should not get velocity credit for that. That is exactly as in your position above and you’ve stated it well. But what about bugs from a year ago? I prefer to estimate that work in points and give velocity credit for it. If you don’t, we will end up in the silly “is it a bug or a feature” debates. To a user there is no difference. I would, of course, love to go back and take away a few points of velocity from the sprint last year but that’s impractical. And since I will be using recent velocity to make release planning predictions I don’t really want to understate that velocity by removing any credit for the fixes. All of this said, there can be exceptions. If we ever feel a team is somehow abusing this to artificially influence their velocity, the behavior needs to be stopped.
Awesome article Mike-
I have to say, though, that I like PÃ¥l’s approach. Not implying by this that yours may not be useful. I just have difficulty accepting your examples.
For me putting in the board “upgrade all developers desktops to Vista.†is just like putting “Sally goes on vacation for a week” or “Take an extended lunch on Friday’s” or “Frank’s computer broke down and needs to be repaired”.
I would simply ignore such tasks, and consider that time as if a developer was not available for that sprint during an amount of time. It is the same thing for “meet with facilities about new cubicle arrangementâ€.
I would simply count those as lost time.
As for your other example: “Meet with Steve to go over his needs for the next versionâ€. This seems to be a task not even related to the current release. This is for the next version. You may just as well include, “meet with my boss for my performance review” or “have a lunch with a potential client”.
Again, I simply think these examples represent miscellaneous tasks that simply should not be part of the sprint. I do not see how those things could be related to the successful completion of the sprint goal. And if a team member is going to invest time doing it, then we can reflect that on the sprint by estimating less time for that team member.
Hi Edwin–
Thanks. You’ll notice that I agree with PÃ¥l’s approach as well when there is a logical place to put the work.
I obviously agree that “Sally goes on vacation” and “take long lunch” should not be represented as tasks in the sprint/iteration backlog. However, I believe that the example of “Upgrade all developers to Vista” is fundamentally different. We can’t really do anything about Sally’s vacation. She presumably has earned and needs that. However, there is a cost to upgrading to Vista (or Mac OS 10.5 to be fair) and I tend to want to make that cost visible so that we are sure to think about whether or not to take on the work. Since there’s no decision about Sally’s vacation, it can be treated differently.
As is often the case, much depends on the context in our heads as we communicate about this. The context in my head for the task about meeting with Steve to go over his upcoming needs was this: We are almost done with a release; we don’t want to finish this release of perhaps 3-months work and not be ready for the next release; someone needs to talk with Steve for a half-day so that he (the product owner) and we are ready to go on the next sprint.”
I occasionally get calls to “come help us as we spend 5 days doing sprint planning.” These calls used to baffle me. How can it take five days? I saw enough of these that I can generalize them this way: The team starts a sprint planning meeting, they have too many legitimate open issues to finish, they spend the next 4 days getting answers to big questions, they convene on the fifth day to do what should have been done on the first day. I call these “billiard ball sprints”–one sprint bounces into the next and pushes its start date out. That is avoided when a team “grooms the product backlog” in this sprint to be ready for the next sprint. This shouldn’t usually be more than 10% of the effort of a sprint but it should happen in most sprints. That was my context with the Steve example.
Wrapping up, though, the most important thing is that a team handle all these types of issues consistently from sprint to sprint. If they do that, their planning will be easier.
Track stories not tasks.
Bugs are a waste, try to fix the root causes rather than finding ways to accomodate them in the process.
Wrapping up, though, the most important thing is that a team handle all these types of issues consistently from sprint to sprint. If they do that, their planning will be easier
I dont buy that. When conditions chance, they need to inspect and adapt and find better ways of handling issues.
Great explanation and examples! I couldn’t agree more and appreciate the reference to share with others.
I’m wondering what you think about extending this philosophy to continued COTS integration. Many of our products are based on enterprise level COTS which are updated and released regularly. Could we extend the “tasks that enable the team to perform the other work” concept to COTS integration? In practice, the test suite is being developed as time and functionality move forward.
Hi Mike–
I think the approach is suitable for any work that is a small percentage of an overall iteration and occurs at unpredictable frequency. Anything big and predictable (e.g., moving to Vista because my COTS partners require it) would be something I would treat as a full product backlog item / user story rather than lumping it into a Miscellaneous category.
Hi Mike,
Nice articles, it really helps me in solving some problems I encounter in my first Agile Experiences.
I have still one question regarding non-story tasks.
Do we estimate tasks that are used to resolve technical debt? We sometimes feel the need at the end of a sprint to review some code and get some things right (architectural & technical). I don’t like to add a refactoring task to our task board since this is meant to be a continuous effort. I spend a lot of attention to code quality, since not every developer feels the same way about that, we often end up pairing a whole day to refactor the code.
Hi Yoeri–
I’m trying to formulate an exact description that captures my view of what goes in the sprint backlog. I think it’s this: The sprint backlog contains all plannable work of any consequence that is not best reflected as work that repeats from sprint to sprint.
So by that I mean that the sprint backlog:
So, to your specific question: If your team has a understanding that when there’s a bit of time, you spend it refactoring then I would not put up tasks for that. But if you have plans to spend a full day refactoring as a pair one tough class, I would put a task for that.
Here’s a sanity test I use: The number of hours planned into a sprint should be relatively stable from sprint to sprint. (This is known as the team’s capacity.) If you agree to do a big refactoring (16 hours, say) in one sprint but don’t put tasks up for it, it will look as though the team’s capacity was lower that sprint. I don’t care how this looks to management; this number should be of no interest to them. (They are interested in velocity.) But the team uses capacity to plan each new sprint: if the team finished all planned work last time, perhaps the number of hours they can commit to next time should go up a few. Leaving a big refactoring out of the sprint backlog would make this very difficult.
Mike, what would you do for major backend changes that are required for other user stories, but don’t actually work well as a story (since it isn’t a deliverable from a business perspective)?
Let’s say I need support for international characters as part of a project with several front-end changes spanning multiple sprints. Pretend I need to do a fair number of complex database migrations to support international characters (pretend our database doesn’t support changing column types). If these migrations will take up to 4 weeks, including testing and moving to production, and we’re doing 2 week sprints, should I consider this one large story, with the Role being the “System” or something along those lines? Or, of I can break it into several pieces, should I still call them “stories”, or just forget the agile methodology for a few weeks and manage the project with tasks?
Hi Andrew–
First, I’d treat that as a non-functional requirement. Non-functionals can also be written as user stories. I’d write the one you suggest as something like “As someone whose language includes extended characters, I can enter such characters in all fields of the system.” If there are a lot of those fields, I’d consider this story to be an “epic,” meaning simply that it’s a big ‘un. I’d then break it down into parts that fit within our sprints: “As someone whose language includes extended characters, I can enter such characters on all of the admin screens” and “As someone whose language includes extended characters, I can enter such characters throughout the order processing workflow.”
I need to blog for November. I’ll try to do so on the subject of non-functional requirements so stay tuned for that as a new posting, probably the week of 10 November 2008.
Thanks Mike, that’s what I was thinking based on your article and previous comments. I may also see if it makes sense to tackle both back-end and front-end changes at once, with vertical slices, so we’re delivering full functionality in different parts of the application with each sprint. The entire application has to be covered, so in theory nothing is truly deliverable after a single sprint, but it might be an easier way of tackling it.
Thanks again for the help, keep up the great work.
Hi Mike,
thank you for this helpful blog posting.
There is one question in my mind to which I did not find an answer up to now:
How to count the effort of larger refactorings, i.e. at the order of several person months?
The background:
We’re working on a software which consists of legacy-code from the pre-Scrum era.
The team was asked to estimate a new feature.
They returned: if the Product Owner wanted them to add it in a former,
so called spaghetti style, then it would be 5 Story Points.
On the other hand, when implementing according to their new insight
and use the new structured architecture,
the feature would estimate to 20 or 40 Story Points.
In both cases the same functionality is delivered to the customer.
Several solutions came to my mind. Which one would you prefer?
Or do you have another suggestion?
a) Do not count for refactorings – even not for larger ones.
b) Do count for refactorings – since they belong to daily-business.
c) Introduce a second measure: value.
Using solution a) the mentioned feature would be at 5 SP .
Using solution b) it would be a e.g. 20 SP feature.
Using soution c) it would estimate to 5 Value Points but 20 Story (effort) Points.
I tend to use solution c). But, it has a drawback since implies that effort for adding new functionality in Story Points is proportional to business value.
Hi Michael–
A couple of key points before I can address this:
a) I’m reluctant to call something of this magnitude a refactoring.
b) I never talk about “value points” which I’m assuming is the value of a story or small feature.
Especially given those points, I don’t see any reason at all to estimate this new feature as anything but 20 points. I would probably have a conversation with my product along the lines of “This new feature is in the middle of some ugly code that has just degraded over the years, especially back when we rushed a few changes in a year ago. So we have two choices in how we implement the feature. The first option is for us to fix up that ugly mess while we’re in there. We’ve estimated that at 20 story points. The second option would be to find a way to slam this feature into the middle of the ugly code. That’s probably 8 points. Now before you jump at the 8 point option, let me explain something. Every time we go into this code as it sits today, things take a little longer than we all wish. For example, if we’d fixed this code already, I’d probably tell you that adding this new feature would be 5 points. That is–almost half of the 8 I’m telling you it is now. The difference, those three points–come from having to add this into the fragile code we have today. If we’re going to be back in this code much–and you’re the best judge of that, Mr. Product Owner–we really need to bite the bullet and fix this code now before things get worse.”
When performing user story gathering sessions, I prefer to iterate through the hidden users of the system, namely developers, project managers, etc… Anyone that will be interacting with the system. I then generate stories like “As a PM, I want to PCI ceritify my network”. I get these non development stories on the backlog. If I don’t, its too easy to loose them and too easy to not allow enough time to complete. http://skeptek.com/2009/09/11/tips-for-effective-user-story-gathering-meetings/ has a few more user story gathering suggestions that I’ve come up with over the years.