[quanticle]

The problem is that research and prototyping is difficult to estimate even when you have a history of estimates. The advantages of scrum really kick in around sprint #4 or 5, when your team has a history of estimates that you can refer to when you're estimating future work items.

In a research setting, this breaks down because the work for sprint N is totally different than the work for sprint N-1, which means that you can't use the work logs from your previous sprints to estimate the next sprint's work.

[einrealist]

If you cannot estimate something, then you should do it in a timebox over and over again, until you are satisfied. If my project requires lots of research and prototyping, I still have valid and useful options in Scrum.

For research, my team will have short sprints with timeboxed backlog items. The result of a research item can be a presentation of the discoveries and a vote / discussion on what to research next (sprint review). If my team's research isn't done within that timebox, the findings are presented anyway and the team / stakeholder may decide to simply file a new backlog item on the same topic for the next sprint. Or the incomplete result is a sign of complexity which can be split into many backlog items. Such items can be that the team decided to get external consultancy or a product presentation by a vendor.

If the team has to mix research with prototyping, it could do two types of sprints: short research sprints as explained above and longer implementation sprints for the prototype that are based on the research results. For example, the team may require two, one week sprints for doing research and then a two week sprint for implementing or continuing a prototype. At the end of each sprint (sprint review) there is a decision on whether the next sprint will be a research or a prototyping one.

So Scrum is still a valid method that enables a team to even steer research and prototyping efforts. This is where Scrum actually shines, because it gives you flexibility and transparency (!) in an uncertain environment.

[quanticle]

That actually sounds like a really neat process and I'm glad it works for you. One question I have is about how you measure velocity with variable length sprints. My understanding of scrum is that the point of having fixed length sprints is that it lets you easily estimate how much you can deliver in a sprint, since each sprint is the same length.

If you have different length research and implementation sprints, how would you estimate the amount of work (whether in story points or whatever else) that can be done in a given sprint? Is it a matter of making sure to compare "like to like"?

[Domenic_S]

> which means that you can't use the work logs from your previous sprints to estimate the next sprint's work.

But you're not supposed to do that anyway. Story points are always relative, so your tasks (in sprint) are relative to one another.

We always "effortbox" our research tasks into a set number of story points.