It would be great to see you in Oslo. I’m there in September and am always excited to travel to Norway.

Thanks for the prompt response! So what you’re saying is, as long as there is a clear commitment that what’s done is really done, and that by the end of Sprint #4 we’re indeed done with the features committed, there will be no temptation to brush anything under the rug. Personally, I trust the team to do that and can work with the Scrummaster to help them keep this promise (they are still rather new to Scrum but very motivated).

Here’s an interesting analogy. A cab driver once told me that, on average, by the fourth hour of his shift, he’d just about paid for lease, tax, gas, and car wash. Anything else he would make from then on, he would take home, so if he got a particularly good fare, he could come home early. I argued with him all the way home that while lease was a capital expense, tax and gas were operational costs and he couldn’t just be “done” with them while production was going. He, on the other hand, knew his average income per shift so statistically, tax and gas were quite predictable, too. We never came to an agreement but obviously he made a point with me if I still recall the conversation after five years

My concern remains with bugs being stored in a separate system (don’t get me started…) with no time tracking capabilities, so the directive right now is to just “close as much as you can”. However, even under these limitations it should be possible to track a separate velocity in #bugs/sprint, and use that for estimation and planning. We close several dozen per Sprint so the law of large numbers should apply. Either that, or I manually pull them in the Agile system and the team estimates them in points. As you might imagine, being a Product Owner this overhead doesn’t make me all too happy. We’ve already agreed to track defects on current deliverables in the Agile system as part of the story they belong to. Hopefully when we clear enough of the bug backlog we’ll be able to get rid of the second system, and the necessity for 60% “hardening” sprints.

Thanks again! Hope I can make it to Oslo

I’m not sure I’d do things in that sequence. But, in the situation you are describing, I can see a possibility that I would want to add new functionality first. After all, the app is buggy as can be already. There’s a lot of uncertainty in the new functionality and the team will be in trouble if it isn’t added on time. So they want to add it first. They probably also think that it won’t matter much if they fix 438 or 461 bugs during the latter 60% of the project. So, there’s some logic to the sequence in which they want to pull work. I just wouldn’t call those hardening sprints.

Good luck!

I realize this is an old blog but it seems to age like good wine

I just saw the next release plan for our product and was horrified to see four “feature” sprints and no less than six “hardening” sprints, with the first two doing actual coding, and the last four doing deployment, staging, UAT, beta and fixing defects arising from those.

Is this even sane? How does the team maintain sustainable pace with feature freeze 40% along the way? How do they focus on quality if they know, up front, that they have more time to “finish it up” than to do it right in the first place? How do you get fast feedback if it takes 50% longer to get software to the customer than it takes you to actually write it?

The main (and quite valid) concern Engineering has is a huge inventory of bugs, in the thousands. It seems they want to do features first, then spend some time fixing bugs. Wouldn’t it make more sense to devote some time on each sprint (50% of the velocity even) to improving the code base — refactoring, fixing bugs, whatever the team thinks fits best? Make the release six sprints long, too. Yes, you get half the velocity for 6 sprints vs. the full velocity for 4 sprints, but I am willing to bet the improved code quality, better packing of large and small items, and sustained pace would make up for it. Once the six sprints are up, tag it, branch it, put it on staging and start a new release as long as the staging/UAT/whatever cycle of this one is. This way, you have one release done with better code quality run in staging, and another one incorporating all the fixes + new features, in the time frame originally envisioned for just the first one.

Does this make sense? Did I just ask for my last check when I suggested it (rather vocally, too) to management? How do you see this release plan playing out in real life? Thanks!

I have come from a heavy SDLC background, mainly implementing ERP systems such as Siebel and SAP. Generally in these sort of projects after build is complete, the project enters System Test, System Integration Test and then UAT. If the release is into a live environment, Regression Test will be added to that list.

With clients moving from waterfall to SCRUM, how do you explain to your clients how SCRUM will address these phases of testing?