“How long is your iterations?”
The question is easy to answer, isn’t it?
Usually you call your iterations “sprints”. Your sprint is two-weeks long, or one-week long, or three-weeks long, etc.
Is it really?
An iteration
What is an iteration?
For me, it’s the time between the moment when you plan what you will do and the moment when it’s done. The real done.
The difficulty to define when you’re planning
When I ask teams when do they start planning, the usual answer is “at the sprint planning”. But then, I dig a little bit, or I watch them doing the planning.
What I can see is that, often, the designers work with one sprint in advance: sprint n-1.
When I ask why, then the answer is always that designers need this time to create the mockup, so the mockup is ready for developers to help them estimate the complexity of the development.
This is the moment when I may say something like: “So you told me your iteration was two-weeks long, I can see it’s four-weeks long”.
“No, our sprints last for two weeks”.
But that’s not what I see.
The time of the decision, matters
I don’t see a two-weeks long iteration, because the team (or the Product Owner) decide on what will be done, two weeks before it will be developed.
So, as the decision has been made, it is set, and as the team NEEDS mockups to start the development (or they think they need them), they have no choice to start working on what has been set two-weeks earlier.
If, for example, during the sprint review (for a scrum team), the stakeholders bring some information or feedback encouraging the team to change the plan for the next planning, then, the team will not be able to change its plan, because designers won’t know how to deliver the necessary mockups.
To adjust from a feedback, the designer will have to work on mockups, while the development team will have to work on something else (or just wait, but I never see that happens). So the reaction time of the team is comprised of the design part, and the development part.
Done-done?
And of course, the result is the same if the team (or worst, someone else), test the product after the iteration, resulting, many times, by doing iteration three times longer than what is said : 2 weeks of “sprint n-1” design, 2 weeks of development and then 2 weeks of “test sprint”, which means that between the moment when the decision to work on a feature is set and the time when it’s really done, 6 weeks may have been spent.
Conclusion
You could say that finally, you don’t define you’re iteration time just by saying so, but by acting as you say. If your want your iteration to be two-weeks long, you shouldn’t start the work before that, and you shouldn’t finish it after 2 weeks.
Of course, having longer iteration is not necessarily bad. Cheating on the iteration duration, is. Face the truth, and reckon that you have two or three times longer iteration. If this fact is not enjoyable for you or the company, then, it’s a perfect opportunity to start asking what to change to do a real two-weeks iteration.
So, for you, how long your iterations really are?
Photo by Omar Flores on Unsplash