Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Spikes are mostly quick research tasks aimed at establishing the feasibility or prototyping of some idea. Thus, they are structured so that the tasks either finish-fast or fail-fast.

However, when a dozen or so spikes are added to the current sprint, there is a possibility that several of them will fail-fast altogether. Let's say there are 4 possible ways of doing something, and the task is to choose the most suitable one and come up with a prototype. If the first attempt fails then try the next possible way, and so on. If the first pick is already a clear winner, then the next 3 aren't necessary anymore.

So, when the current sprint consists of mostly spikes, does it make sense to also shorten the sprint time to maybe a few days, so that reprioritization can happen more frequently?

share|improve this question

2 Answers 2

up vote 5 down vote accepted

The key word in Agile Methodologies is Agile. If you can't adapt to more appropriate ways of doing things, especially temporary changes in process, then you are missing the point.

Too many people get hung up on dogmatic adherence to Agile Methodologies check lists of what is and what isn't Agile, and if you aren't doing every one of those things religiously then you are wrong. Those people don't get it.

If your team needs to adjust or adapt for a Sprint, then it should be done.

share|improve this answer
    
+1: And. The alternative -- sticking to the schedule even if the sprint's work is done -- seems to be extremely stupid. Worse, that related question (stackoverflow.com/questions/5475676/…) was shocking in it's implication that scrum schedules are rigidly fixed. –  S.Lott Apr 23 '11 at 12:28
2  
That's almost Taoist: the Agile methodology that can be strictly followed is not the true Agile methodology. –  David Thornley Apr 25 '11 at 17:02

In Scrum you would not shorten the current sprint, because it would break your velocity computation and make it more difficult to estimate the right amout of stories for the next sprints.

In Scrum the product owner can do prioritization on the product backlog while the team is working on the sprint backlog. When the sprint backlog gets empty early, you can pull more stories from the product backlog to the sprint.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.