We have already had User Story as most popular tool. But this is not the end. Today about Iterations: the small and big ones, these that are completed and those that are never stopped.
Iteration is a period of 1 to 4 weeks. During this time Customer needs to decide what is the most important at this moment. 4 weeks is also called the Sprint but we prefer Iteration as it’s stronger option.
Iteration is not only about programming but also about tests and more. Actually tests are run before the programming phase.
We also have to mention about infinite period. In this case Iteration is one, only User Story has to be completed in some period of time and then disappears. In this place another User Story appears. Customer tells about that User Story and if it’s good we start with the new one.
I find SCRUM’s “sprint” a very intriguing name for an iteration. In the heart of agile development there is continuous delivery of a working software. To do that we time-box software development into iterations / sprints.
They have their rhythm and require different kind of discipline from our team. We become sprinters who continuously plan, test, implement, evolve architectures, deliver, improve the process, celebrate to finally be back in the starting blocks to launch another sprint. We do that iteration by iteration.
Can sprinter be a long distance runner?
A very common technique in agile projects is tracking team’s average velocity. It’s said that it should stabilize after few initial iterations on some level. This is also called finding a sustainable pace for a team, which in short means that our team members commit to just enough work to become productive without burning out to early at the same time.
I’m not going to convince you here why a sustainable pace is a good thing and why a tired developer is not going to be efficient and creative. It’s the opposite that always intrigues me in the name “sprint”.
When we sprint, we put all our energy to run a short distance (a single iteration) the best we can. However we plan our efforts differently when we are about to run a marathon of 20 iterations. So how long are we able to sprint and keep our average velocity constant?
Is there a point at which the team will start to loose it’s velocity? Well the answer might be that that’s where the sustainable pace comes to mind. We do not overcommit and we in fact stop sprinting at the maximum available velocity that we can achieve to sustain the pace.
Sustainable pace or sustainable undercommitment?
So how do we distinguish sustainable pace from sustainable undercommitment? Where is that point that we know we should not commit to more work as a team without being accused of just not being willing to do more while hiding behind a very nice term of “sustainable pace”?
My answer to that is great people, trust and transparency – all being the key parts of agile development. What is yours? How do you keep it at the level everybody accepts?