![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgewA2oCZq-2Cesbm8PrItCmgsEYcCy_SClLVGmjTv29Hi4hfJ1G3S_UirhtbTmrIeG7HNffhyphenhyphenPkU0lHXXc71ExVSBgpAGAzo30enyn6AGFR166cWLfBzTatHK1AcMXutorinBqU0CVaag/s1600/splitting_logs.jpg)
Often times iterations become boxes of features – when planning the sprint
the question asked is “what can you deliver in 2 weeks” as opposed to “what can
you grow in 2 weeks”. Creating two week
feature boxes is encouraged by a lot of authors that talk about release themes
– people misunderstand that to mean that sprints should be themed. When push comes to shove the sprint is
extended to meet the completion of the theme.
Sound familiar?
Thinking in terms of a pull system rather than ‘pushing’ work into a
sprint will go a long way. I’ve had
students that said their software is extremely complex and nothing can be
produced for weeks on end. Consider this
– do you compile and check out what the code is doing only after the end of
weeks – I hope not.
A 2 week sprint is 2 weeks of time, not an estimate of what the team
thinks can be completed in 2 weeks which is then extended to accommodate the
estimated features. You’ve got to think
backwards, that will help quite a bit.
No comments:
Post a Comment