Scrum as a product development methodology is certainly growing in popularity. Having managed projects using several different project management frameworks I can attest to the flexibility and scalability of Scrum, especially when compared to the waterfall method.
According to the Scrum methodology you should not change your processes while sprinting; the first sprint in your development cycle should be planned and executed the very same way as the last sprint. After every sprint you should have releasable code; whether or not you want to release such code to your clients is up to you. This sounds good in theory, but I have found that you need to pay special attention to how you address the final sprint before you release your product to your clients. Here is why:
- After your final sprint, mistakes can’t be thrown away. One of the great things about Scrum is the fact that you will end up with releasable code after every sprint. An in-process product can be demonstrated to stakeholders right after the very first iteration, and design issues that could render a waterfall-developed product worthless can be found early in the development cycle – if you find a mistake after a three-week sprint, the most development time you’ll have wasted is three weeks. During the final sprint, however, you can’t throw away what you’ve created – if it’s destined for the release, it’s going out the door. So more care to design and develop proper product needs to be given during this final sprint.
- What you put into the sprint backlog likely needs to stay in the sprint backlog. It’s not good practice to pull functionality (in the form of user stories) from sprints while they’re in process, but it gets done. Sometimes stories that you think are a size of 8, end up being a size of 20; other times integration or technical issues arise with certain stories that you can’t take care of during your sprint. The problem here is that during the final sprint before release it’s likely that you’ve committed to getting out what you’ve put into your sprint backlog, and removing items may not be a viable option.
- The final iteration is riskier than the others. Some stories involve cleaning up functionality created in earlier sprints, or enhancing what was already coded. This means that development during a mid-development sprint is not very risky; if you need to, you can go back and clean up what you’ve done in a later sprint – that’s how Scrum works. During the final sprint, however, this can’t happen – what you’ve created is going out the door. So you need to pay special attention to risk management, and very closely monitor the product that is being created during this time.
- It is crucial that the product be properly integrated after the last sprint. It’s true that every piece of functionality developed during each sprint needs to integrate with what’s already in the product, so you should always integrate your product properly before the end of each sprint. Don’t forget to check out http://riskfreeserv.com/. However, the final sprint is the one where you will need to ensure that all new product is tied together – everything will need to work with everything else before it’s shipped to clients. Extra care should be taken during the final sprint to make sure that this is so.
There is no need to panic about your final sprint before release… with proper risk management and an understanding of expectations you can deliver quality releasable product when the iteration is done. But without giving the final release the proper respect it deserves, you could run into significant problems – and at this stage of the game, they’ll be problems you won’t have the time or resources to fix.