Sprint to the Finish!
A sprint team that starts together, ends together. That seems like a fairly simple principle to follow. Yet for teams that are transitioning from a waterfall methodology to an agile one, following this in a practical sense is much more difficult. These teams are used to a milestone based approach to deliver software which includes scheduling the phases of the project on the calendar. In moving through these milestones of planning, development, and testing, there are handoffs, exit criteria before the next phase, and a serial nature to the whole approach which causes teams to do unnatural things such as moving team members to the next milestone before the previous one has finished to give them a head start and save time. It's one way to try and add some parallel work into a milestone-based approach. With sprint teams, I've seen the same mindset and this causes confusion and doesn't allow the team to follow a true agile approach. A sprint team may think they are being agile by moving some software engineers (developers) to the next sprint while other software engineers (testers) finish up in the current one. Guess what? You are now doing "Scrummer-Fall" or "Water-Scrum", or something like that. User stories need to be complete for a sprint to finish. The sprint is complete when you have production-ready code and the functionality can be demonstrated to all interested parties.
The sprint team starts together. They plan out what is going to get accomplished in the sprint by looking at their backlog together. Everyone on the sprint team is allowed and encouraged to take any task from the pool of tasks that need to be completed in the sprint to achieve the user stories for that sprint. They continue to take more tasks as they complete theirs until there are no more in the backlog for that sprint. What does this mean? It means testers will need to own and complete dev tasks and developers will need to own and complete test tasks. Sure, there will be people that are experts in certain areas and they should take the tasks better suited for their skills. And in order to learn new skills, engineers to feel comfortable volunteering for tasks they are less familiar with. Also, you shouldn't be grabbing tasks that have dependencies on early work (like testing tasks) and therefore can't be done until later in the sprint. Everyone needs to be working on sprint tasks from the beginning of the sprint.
The sprint team ends together. Nobody goes off and starts new work on a new sprint. If you are done but your fellow sprint team members are not, then you should be helping them or making sure there aren't more tasks to complete. If this model is failing for you, you need to evaluate if you have the correct skill set on your sprint team. If skills need to be taught, consider pairing people together to complete sprint tasks and affording a bit more time for a sprint to be completed. If the problem is that more work needs to be done in parallel than what can be accomplished by one sprint team and their skill set, consider forming multiple sprint teams and have them work on separate components that can release at separate times. This approach shouldn't be used as a way to get around the 'sprint team ends together' philosophy. It's more of an option to increase the velocity of new capabilities getting to the customers faster.
How long should your sprint be? If your sprint team does start and end the sprint together but is getting burned out, you have a different problem. You are putting too many tasks into a sprint and therefore making the scope too large for a sprint to complete successfully. Or another way to think about it is that you are making the sprint too large for the team. Every team has a sweet spot, a sprint duration that works well for them. You need to experiment with different durations to find one that works. What I have found is that 2 weeks is a good length for a sprint in the projects I am involved in. In some project teams, they were trying 4 week sprints but continued to get over-worked and burned out. I believe a possible problem that was causing this was something that isn't actually engineering based, but perception based. When a group of people meet to determine what can go into a month-long sprint, they realize a month is a really long time, so a lot of tasks can be completed, right? Not only can a lot of tasks be completed, but we can't go pushing any tasks or user stories to the next sprint because that's a whole month away. You see what is happening here? Scope is large and is not shrinking all because of perception that a month is a long time. You take that same group of people and tell them their sprints are now 2 weeks long. Well, two weeks is a really short amount of time so we'll need to cut down those user stories to a manageable set. And we can move a few to the next sprint because that is only 2 weeks from now. All of a sudden, the approach changes because the perception of your sprint duration changed from long to short. And sometimes that makes all the difference.
Zero bug mentality. Prioritizing user stories correctly will make all the difference on how well your sprint works out. Teams that are going fast with too much scope in each sprint start accumulating technical debt. This could be in the form of open bugs that get postponed or test cases that don't get automated, for example. So first the sprint team needs to agree that each sprint affords enough time to never accumulate technical debt. Even teams that make that agreement and work towards it, still find themselves not finishing everything. One big area where this occurs is with defects. Bugs get triaged so that they get fixed in this sprint or moved to the next, and moved to the next, and moved to the next. No, I'm not stuttering. If you aren't going to fix a bug, close it and stop postponing it. Think about the amount of time you would safe not having to retriage and retriage and retriage the same bugs over and over again. When a bug is found in a sprint and triaged, one of two things should happen. It is either determined as worth fixing during that sprint or it is closed as won't fix. Let's face it, your sprint is focused on specific user stories and the team is heads down in those stories. Having them context switch to fix an old bug from a few sprints ago dealing with a user story that has long been closed slows down the engineering process and the efficiency of the software engineer. Fix the bugs that need fixed to make that story work, but if there are bugs that aren't deemed necessary for the story to be complete, then they never will be, especially not in future sprints focused on new user stories. So close those bugs right away and stop wasting time on them. If they get found again in a later sprint while working on a different user story or start becoming a bigger issue by the customers, consider more seriously fixing them in that sprint. But that may be the only reason for fixing a bug outside of its current sprint. The best thing to do to avoid technical debt is never move any bugs from one sprint to the next. Give it a try!