I will be honest, I have not answered this question in my own mind yet, but I thought it would be good to have a group discussion about the potential pros/cons of not using sprints/iterations when applying agile.
Why do I question this?…
It has always bothered me that sprints are always of the same length and we need to fit our scope of delivery to this rather arbitrary sprint length. I understand some of the values of having a fixed sprint length…but still I wonder if it is the best way.
Maybe I have been doing agile wrong for the past 10 years, but I always seem to see some challenges caused by the existence of a sprint with a fixed length.
lets start with this one…
When requirements authors (BAs / Product Mangers etc) craft their requirements they don’t really take into consideration how long things take to build when they define a requirements, story, storyboard etc. So this means the dev team needs to break down these requirements into smaller chunks and deliver only those chunks during the sprint. I typically see two issues when this happens.
1) It can often unclear what subset of the requirements the developer is actually agreeing to implement. We have tried breaking down those requirements into smaller chunks/stories, but then we just end up duplicating the statement of the requirement in multiple locations, and equally importantly this takes time that seems almost like a waste of time.
2) Sometimes what can be delivered in the duration of the sprint really is not a great logical breakdown of what we want to see delivered. For example let’s say the sprint is 2 weeks, but the work that can get done and completely tested within 2 weeks really does not make sense, but what could be done in 2.5 weeks would make sense.
I know and have applied techniques to break down the work so it fits into the sprint, but my point here is this takes time away from building the solution, and can cause confusion as to what the scope of the sprint is if not done in enough detail.
I have been experimenting with a different approach here at PowerStory where for a given product release we essentially have a continuous backlog of stories / bugs that we want in the next release and treat that release as one long sprint. That sprint might be anywhere from 1 month to 4 months depending on the goals of that release.
The result has been interesting. The net benefit I have seen is that we spend less time managing and more time defining and building the solution.
Martin Crisp CEO, PowerStory