Have you ever wondered exactly what types of things a team does during a Sprint or what they should be doing? A team usually has one thing on their mind during a Sprint: “complete our commitment”! However, there is a bit more wrapped in that commitment getting completed which the team needs to consider.
Something teams use to know if they complete their commitment is a Definition of Done. As a team develops their Definition of Done, they assume certain things, which frequently center on the most obvious like coding and testing, will be completed during the Sprint and base the Definition of Done on those. Nevertheless, there is much more that should be considered for the Sprint. By using what I call “The Sprint Bubble” as a guide, a team can construct their Definition of Done to ensure they do everything they need to do in order to complete their commitment.
In addition, by using the Definition of Done as a guide, the team will be much more comfortable with what they expect to complete during the Sprint and will identify things which should not be done. It is worth reviewing those as the team builds the Definition of Done as well.
A lot of teams think the Sprint is nothing more than a ‘mini-waterfall’-type timebox; which is not the case at all! While there are many things which go on during the Sprint, they are absolutely not done in a ‘mini-waterfall’ style. Using “The Sprint Bubble” (shown below), you can more easily identify the things that have a place, or not, in the Sprint. I like using the MoSCoW-based categories—“Musts”, “Shoulds”, “Coulds”, and “Won’ts”—to explain. These things, regardless of category, are simply a way to construct the Definition of Done. There are times when you may have a bit of order to be followed, but these things just need to be completed.
First, let’s look at the “Musts” that belong in “The Sprint Bubble”. The most obvious things are develop and test code. However, given that testing is usually broken out into multiple different types—unit, integration, functional, story, system integration, performance, user acceptance, and so on—there will be some that may fall into other categories. With that in mind, the unit testing and functional testing would be a must because they help to ensure the stories are completed and functioning correctly. Also, many teams are moving more toward story testing (also referred to as acceptance testing), which is defined as testing around each and every story to ensure it meets the acceptance criteria of that story. When teams are doing this style of testing, it is also considered a must. Another must is integration testing; teams need to ensure their pieces work together and integrate well in order to make sure the entire product works well.
What about things like design or user interface components? These would be categorized as “Shoulds”. Before we talk about what things are categorized as shoulds, what does it mean to be a should—well, it means that it is something that belongs in the Sprint, but will not necessarily cause a ‘break’ in the application that’s being built or overall Scrum framework if it’s not. A lot of what you find categorized as shoulds are designated as other teams’, or organizations’, responsibilities in larger companies but would be musts in companies that don’t have these other teams or organizations. When you have a company without these other types of teams, design or user interface components should be done inside the Sprint and be part of the team’s Definition of Done. When a company has a different team or organization that does these types of things, they may decide these things are to be done and approved prior to the story being put into a Sprint. The one thing that many teams seem to forget is documentation. Documentation is a should, and therefore belongs in the Sprint, which helps to ensure it never gets overlooked. Another thing that would count as a should is that of system integration testing. System integration testing is very important to the overall product and is required to ensure the newly created product plays well with what the organization already has in place.
That brings us to “Coulds”. There is some easy stuff that could be put into a Sprint based on the company and the ability to do it in the timebox. Coulds are things that some may argue belong in the shoulds, but the way the organization is organized or the way the environments are set up may more appropriately put them in could. Probably the most popular detail that falls into coulds is user acceptance testing. This is something that seems to have the most problem being put into a Sprint due to the amount of time that the UA testers can lend to the Sprint timeframe or environment setup. If you have none of these kinds of restrictions, the user acceptance testing can most definitely go into the Sprint and therefore will allow for a release to production after the Sprint. Performance testing is another could, but will also be done in bits as other types of testing are performed (another topic for another day). I try to have performance testing be more a should than a could, but again relies on how the organization and its environments are set up.
Well, now we are at the “Won’ts”. A few things definitely do not belong inside a Sprint and need to be defined as such. One of these is defining acceptance criteria for the stories already in the Sprint. If you do not have acceptance criteria on a story, then the story is not eligible to be put into the Sprint in the first place. Another is defining a story to work in the current Sprint. If a story is not well understood, it cannot be accurately estimated, which also means it cannot be worked properly and cannot be put into the current Sprint.
Hopefully by better understanding what work is part of a Sprint, a team’s Definition of Done can be better constructed and followed. By using “The Sprint Bubble” as a guide, it helps the team solidify what should be part of their Definition of Done based on their environment and company policies. Having a solid Definition of Done means the team can ensure they are producing the highest quality of a valued product at the end of each Sprint.