Whether you call it a sprint, an iteration, or a timebox, each incremental delivery of your Agile project is time-constrained. The timebox doesn’t shorten and it doesn’t lengthen. Focus on two-week iterations at the beginning. You might find that 1, 3 or 4 weeks suits your business model better. Once you choose a length, don’t change it. You want to maintain a regular cadence, or a sustainable pace. This means the team and business focus on delivering regular software without mad-dash overtime being employed to get the job done and releasing potentially shippable increments every two weeks.

·         Working in small increments has a huge benefit. It means you’re only focusing on the immediate future of delivery and, with new input, feedback, and learning, you can respond to change within a short iterative cycle.

·         At the beginning of a release, perform a sprint 0. This lets the team, the business, and your project release get geared up and sets the mindset for successful delivery. Draw out the base technical framework and architecture that will support the foundation for the release. Set up environments, accounts, and tools. Perform spikes to understand difficult or unknown problems. Elaborate your user stories in readiness for sprint 1. Sprint 0 is about getting prepared.

·         During a release, keep refining the backlog. As you understand more or learn something new, your priorities may change, new requirements may unfold, and what you previously thought was a great feature may get removed entirely.

·         Don’t start work that has no chance of completing within a sprint. If it can’t, break it down into smaller chunks. And don’t start new work when previously started work has not been completed. You create no value by starting lots of things that can’t be considered complete. Further, avoid context-switching. This is the activity of starting one task, getting disturbed, starting another and, at its most problematic, not completing either.

·         Limit the amount of work that is in progress by the team at any one time. For example, if you have three developers and one tester, you may put a WIP limit on the developers and on the tester.

·         Never add more work to a sprint after it has been planned. Never stop a sprint partway through. The exceptions to this are:

o   If you performed faster than expected, consider taking the next story from the top of the backlog, as long as it is suitably prepared.

o   If the sprint is performing so badly that it will not complete. This usually only happens where there has been a catastrophe of some description.

o   If the sprint objective can no longer be supported due to immediate changing needs of the business.

·         If you do cancel a sprint, do it gracefully, take time to refocus, and start a new sprint as you would any other.

·         Toward the end of a release, consider a final release sprint. No new features are written, some bugs can be cleaned up, and preparations can be made to actually release a new version of your product to your customers. That’s not to say you can’t make incremental customer releases in the meantime—it’s just that this is a controlled, measured, and sustainable release mechanism.

·         At the end of a release, you might consider a one-week sprint. In this sprint, you might work with the team to breakdown some new ideas or figure out some new technology. These are great tools that benefit the business, and it gives the team some briefing space to think and be creative. It’s not for goofing off and will still create value. Equally, everyone needs a break. Taking a vacation at this time helps keep your cadence and velocity in good shape when you’re mid-release.