The concept of scrum can seem very simple in theory. As stories come in, the team analyzes them, and then story points them based on the complexity of the story. It couldn’t be simpler. But in practice, it is rarely this simple. The problem is that sometimes you won’t know just how complex a story is until after you’ve played around with it a bit. At my company, this is a problem we face almost every time we meet to story point backlog items.
Usually, a bit of uncertainty is fine. That’s the entire reason teams usually story point with a non-linear scale (one the popular scales being: 1,2,3,5,8,13,20,40,100). If a story could be anywhere from a 30 to a 40, then just give it a 40 (assuming we’re using the popular scale). Even if the story ends up closer the 30, there’s probably some other story that was more complex than its story point implied and it all generally averages out. But every now and then, there’s just too much uncertainty. A story might be anywhere from a 5 to a 50 depending on factors you won’t know until you’ve looked into it a bit and done some research.
Well then, let’s research it first. And here in lies the problem that our team faces regularly. Researching a story takes time. And it’s not immediately clear how this time should be tracked. We considered everything from making the research a task of the story, to making it a story of its own, to even just doing it whenever anyone had a spare moment. But the solution can be reasoned out simply by adhering to scrum principles. We don’t make the research a task of the story, because the research must be done before the story is even pointed, much less started. We don’t story point the research separately because it’s not value being added to the product, so our product owner won’t want to consider it when looking at how many stories he can add to the product before the next release. So we just add the research to the backlog as a separate task in much the same way we do bugs. Once that task is done, then the related story can be story pointed. And that’s it. These tasks are usually time boxed and quite small, so it’s usually no problem just to throw it in at the start of the next sprint.
This solution may seem simple or obvious to those experience with the ways of scrum. But it’s a question many at our company have had since we’ve started adopting scrum for agile development. Of course, this solution is not the only way to deal with research. But it is a way that works for us and I hope this helps anyone else who may have the same question.
Follow