New-age Transactional Systems - Not Your Grandpa's OLTP
John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.
News
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
When to Extend an Iteration/Sprint
Posted by Mark Levison on Oct 08, 2009
A day before the sprint ends, a problem is discovered in an important story that will prevent the team from completing the story. What is to be done? Push the story back into the backlog or extend the duration of the sprint? Pablo Emanuel says that you can either return the story to the backlog or cancel the sprint. He goes on to say that delaying a sprint violates the principles of iterative software development:
the whole idea behind iterative development is feeding back the process as frequently as possible. You'll feel tempted to delay it, specially in the beginning, but, by the same principle people that have a fixed schedule with a personal trainer show up more often at the gym than people that are free to go whenever they want, you should never delay your iterations.
In addition, he points out that the iteration demo is important even if there is only a tiny feature to show as it provides an opportunity to meet and review the last iteration plan.
Maurice le Rutte notes that: “admitting that you could not finish the item because of the defects you found will increase the team's credibility and thus trust. Delaying the demo will send an entirely other message, namely that you don't have your process in control and that you will be delaying all the time.” He goes on to remind us to thank the team for finding the problem early before the customer did and of the importance of using the retrospective to find out what happened to the story.
Dan Rawsthorne points out that holding the review and retrospective gives the Product Owner a chance to reprioritize for the next sprint and that might not involve the troublesome story.
Another team finds itself in this situation on a regular basis leading the Scrum Master to believe that there was a planning problem. Cenk Çivici asks why stories aren’t done: “Are stories too big? Do they have clear acceptance criteria ? Does testing take too much time? Do you have enough test people to finish stories ?”
Juan Banda reminded us of the INVEST acronym: Good User Stories should be:Independent, Negotiable, Valuable, Estimatable, Small, Testable and wonders if the small part is being violated.
Inanc Gumus explained that the team has only three members (beside the Product Owner and Scrum Master) and that they initially estimated stories as only taking 3 days. An example: "As an advertiser, I want you to stop delivering my campaign as soon as my campaign budget is depleted". The team thought that this was the smallest they could slice up the story.
Paul Hudson offered smaller stories that could later be connected into one bigger one: “As an advertiser, I want to be able to stop delivering my campaign at any point. As an advertiser, I want to be able to know how much I have spent at any point”. Ron Jeffries takes a slight different approach: “First story split out here might be "Given a depleted campaign, do not deliver it". This should come down to two things to do: business logic consisting of about one if statement, and hand creation of a depleted campaign. If it takes more than a half day, I'd like to know why.”
Mark Levison, this reporter, suggested that Inanc ask the team in a retrospective what they think is at issue, using root cause analysis and other retrospective tools. Its likely they already know some of the answer.
The consensus in both cases: alert the product owner as soon as the problem is discovered; demo the functionality that was achieved; allow the PO to reprioritize; use the retrospective to find the root cause; Don’t extend the sprint.
- This article is part of a featured topic series on Agile Techniques and also Agile
- See more Agile Techniques content at: http://www.infoq.com/agile_techniques
- See more Agile content at: http://www.infoq.com/agile
- Other recent content items in this topic
RelatedVendorContent
Five Key Practices to Agile ALM
Transforming Software Delivery: An IBM Rational Case Study
A Guide to Branching and Merging Patterns
agility@scale eKit: 10 Principles, Scaling Model, Metrics, Collaboration
Related Sponsor
Maximize your business-responsiveness with Mingle. Provide your global development team a shared space that adapts to the way they work.
Brooks said...
by
Jim Leonardo
Posted
Re: Brooks said...
by
Mark Levison
Posted
Good conclusion
by
Jun Ran
Posted
Re: Good conclusion
by
Mark Levison
Posted
Re: Good conclusion
by
Keith Moore
Posted
Re: Good conclusion
by
Jun Ran
Posted
Re: Good conclusion
by
Mark Levison
Posted
Re: Good conclusion
by
Jun Ran
Posted
Re: Good conclusion
by
Mark Levison
Posted
Re: Good conclusion
by
Jun Ran
Posted
Velocity
by
Stephan Kennedy
Posted
Iteration length is probably not the real problem
by
Dave Nicolette
Posted
root causes
by
Troy Tuttle
Posted
Re: root causes
by
Mark Levison
Posted
Re: root causes
by
Troy Tuttle
Posted
Re: root causes
by
Mark Levison
Posted
Re: root causes
by
Troy Tuttle
Posted
Re: root causes
by
Mark Levison
Posted
Re: root causes
by
Troy Tuttle
Posted
Re: root causes
by
jussi markula
Posted
-
One of the little bits of advice from Mythical Man Month was "Never slip small" and I think the advice still holds regardless of methodology. Slipping small is a slippery slope (pun intended) because the temptation to simply bash harder at the work takes over. If you never stop to consider whether you really are 'almost there' or not, then you don't know if it's a small slip, or if you're just at the tip of the iceberg. This can lead to two months of "any day now".
The various points made that boil down to "you need to let your customer know" is also important. You may find out that they care a lot more about the next items in the backlog. Some times priority is determined by how much effort it will take and if something will take longer, they may want something else first.
I guess it's also a bit assumed that we're NOT talking about 'stretch goals' here... those items that you start because you have time left in the sprint but possibly won't get done. Those should always go to the backlog. -
Thanks Jim for reminding of that little bit of Fred Brooks. I think he also said that you can only ever slip once. I learned my lessons on this hard way, I spent several years as a command and control manager always trying to balance my gantt chart.
-
Get the product owner alerted as soon as possible;
Demo the features that have been finished;
Find the root cause and solve the problem;
Reprioritize that problem;
Never extend the sprint; -
Thanks Ran. Have you seen this problem yourself?
-
Had this same discussion with my team in our last retrospective. We failed to complete all the stories and the sprint goal. When asked what we could have done one team member suggested that we could extend the sprint "a little bit", in principal it sounded good. However the value gained from finishing the sprint on time regardless of story completion meant that we can review the problems, inform the customer/product owner and decide on a realistic course of action to solve said problems.
-
I have seen this problem myself, in our team, when we failed to complete all features in the sprint, a common trend was to extend the srpint, and we did this from sprint to sprint.
One big problem here is the product owner, our customer, never remove things from the sprint, instead he usually adds more tasks into the sprint. -
One big problem here is the product owner, our customer, never remove things from the sprint, instead he usually adds more tasks into the sprint.
Hmmm - your product owner feels he can add things to the sprint? That violates one of the principals of scrum. The team need islands of stability - the sprint is that island. If the PO is adding stuff during the sprint then this isn't scrum.
I'm sure you already knew that, my next question has the PO had any Scrum/Agile training? -
As far as I know, he hadn't taken any Scrum training, but not very sure for Agile training, looks like the PO knows something about Agile.
Actually, the team here is not completely adopting Scrum, we just adopted some Agile best practices as the situation permits. -
As far as I know, he hadn't taken any Scrum training, but not very sure for Agile training, looks like the PO knows something about Agile.
Then I would get him some help either training (the best option) or at least a good introductory book. I like The Art of Agile Development - James Shore and Shane Warden.Actually, the team here is not completely adopting Scrum, we just adopted some Agile best practices as the situation permits.
The fixed sprint backlog is at the core of why agile works, if your PO won't adopt it - they need to understand why this stuff works: www.notesfromatooluser.com/2007/06/does-scrum-w... and www.notesfromatooluser.com/2007/07/why-scrum-wo... are my explanation from a few years ago. -
Thank you for your help Mark, I will try your suggestions.
-
Another point to remember is that the velocity (story points completed per sprint) is only valid if the length of the sprint is constant. Varying the sprint length makes velocity meaningless.
Stephan -
I think Cenk, Juan, and Mark are on the right track to ask about root causes. In every case when I've worked with a team that wanted to extend the iteration length, either temporarily or permanently, it was because of pressure they felt as a result of not doing one thing or another as optimally as they could, or as a result of external pressure - product owners or other teams who didn't understand this way of working. The impulse to extend the iteration is, in itself, a "process smell."
Lengthening the iteration will not solve the underlying problem. It will only conceal the pain temporarily, until the team reaches the next iteration boundary. IMO an organization should try to squeeze the iteration length down as far as is practical given present realities. If the work doesn't seem to fit in that space, it's more likely because of the way the work is being managed than because the space is genuinely too small. It may also be that an iterative process isn't the best choice in that particular case, and the team can consider an iterationless process instead. These choices can't be made wisely without understanding the root causes of the delivery problems. -
So what happens if the root cause analysis shows the bug was produced as a result of rushing to finish the story in the current time box? Fox example, if good practices are in place, but the story was slightly larger than anticipated, so corners were cut to make it fit in sprint.
-
But if good practices where in place then the team would realize they weren't going to be able to DONE. So they would go back and renegotiate the commitment with the PO. Or maybe they would just finish the sprint without finishing the story. Then the PO can decide to finish or not in he next sprint.
-
I agree, the team would have a better idea of the amount of work by doing acceptance criteria. But can they really tell the difference between 10 days work vs. 10.5 days work? One fits in a 2 week iteration, the other doesn't.
If it takes a team 10.5 days to do a chunk of work that they thought would take 10 days, I don't see that as a problem. I see that as being 5% off on an estimation (something almost any industry would be thrilled with).
In the Agile community, we tend to collectively wring our hands about such things. When I hear an example like this, I think it sounds like a relatively healthy team (they found the bug) that is being beat up because they didn't effectively predict that their work would fit nicely into an arbitrary time slot. -
Troy - I've never seen a team miss by 5%. I've seen teams with 2-3 stories in flight at the end of the iteration. They're velocity said one thing but they committed to more than the velocity being sure they could do it. They didn't.
In addition the pressure to extend the iteration almost always comes from teams doing Scummerfall/Waterations. Fixed length iterations provide pressure to fix that problem.
I realize that Kanban teams also improve - but I'm confused where does the signal and the pressure come from to get rid of Waterfall process inside a Kanban team? Does it come from measuring the length of time to deliver a feature? -
I should add if a team misses with a single story and it gets finished the next iteration. So what. That's not a problem. Teams that are trying to extend the iteration are not missing with one story. They're missing with several. They're concerns (misplaced) are typically: There's not enough time to test the stories; The meetings take up too much of the iteration.
-
Mark,
I would look specifically at cycle time, classes of service, and service level agreements. Kanban teams measure cycle time and can establish SLAs with stakeholders, like "we expect to deliver a medium sized set of features in 8 days." Where medium is t-shirt sizes for relative estimating. And the feature set (called MMF in some circles) is a group of stories the business has determined to be valuable.
The idea ultimately is to reduce cycle time. The pressure comes from measuring actual performance and trying to make improvements to reduce the time by getting better at software delivery. Contrast that with asking a team to "commit" (guestimate) what they will complete in two weeks. When timeboxed Agile teams don't make their iteration, sometimes it's because of bad practices. Other times it's because they weren't perfect at estimation. Why not remove the estimation variable from the equation?
The best Kanban resources:
www.limitedwipsociety.org/resources/
Regards,
Troy -
Mark,
"I should add if a team misses with a single story and it gets finished the next iteration. So what. That's not a problem. Teams that are trying to extend the iteration are not missing with one story. They're missing with several. They're concerns (misplaced) are typically: There's not enough time to test the stories; The meetings take up too much of the iteration."
I was just going by your original example in the article where a team finds bug late in an iteration. I agree, it's not a big deal if it's just one bug in one story. But I have a question about the recommended path (not extending iteration). If that story is important, why make the stakeholder wait until the end of the next iteration for delivery? Aren't the timeboxes getting in the way of delivering value to the business?
Regards,
Troy -
Troy,
I'm lucky I found someone else who dares to question the agile principles. I've been leading a succesful change in an organization, which started from total adhoc, went through beautiful Scrum with perfect burndowns and sprints and now they are using Kanban and delivering value succesfully at a constant rate.
The team had the exactly same kind of questions you proposed: why should we estimate and predict work into an arbitrary time slow, when there is no need for that? Estimating is waste of time, if it is not needed. Predictability costs, if it is not needed. By mainly limiting WIP we can succesfully deliver new functionality at a constant rate without time boxes.
Regards,
Jussi
20 comments
Watch Thread Reply