Intermediary sprints

The main goal for a Release sprint is to have a product release in the end, but when we are not yet ready to release then we also have an option to initiate an Interim sprint that will not end in the product release but will instead produce one or more building blocks necessary for the eventual product release.

Interim sprints are used when the team has unknowns ahead and needs to perform analysis, research, learning in order to be able to know how to plan a future Release sprint in details.

Even if the work ahead for the product release is well known but there is too much of it for the team to finish everything in a single max-length 4-week sprint, then having one or more connected Interim sprints is the solution.

Keep in mind that the main expectation for any kind of sprint is to have finite and measurable deliverables in the end which applies to Interim sprints as well. For the Interim sprint the deliverable will not be a product released to production but something smaller - some examples are:

• When looking for the best way to find out how to develop something then do the hands-on approach: develop a prototype or attempt to build a proof of concept
• It is still OK if this Interim sprint deliverable might not be used in the final product in production as long as we learned from the exercise and can now plan enough time to do it right
• It is also OK if the proof of concept turns out to be impossible to build, i.e. due to technical limitations or external constraints that we have now clearly identified and have removed all unknowns from our path
• When fixing a complex issue or optimizing performance we need to plan out enough time to attempt several or all potential fixes or experiments that will lead to resolution or improvements
• It is OK to have limited incremental success here without committing to specific outcome or specific numbers in the end as long as we have systematic progress and can keep stakeholders updated what worked / didn't work
• When researching and need to figure out how comps are doing things, or to learn more about a subject that is new but without possibility to build a tangible prototype even if it is thrown away in the end: it is OK to just do a detailed summary on the subject or ideally a plan on how we'll approach the next Intermediary or Release sprint

How much time can be allocated to an Intermediary sprint?

• Max-length applies to all types of sprints and it can never be longer than 4-weeks
• If multiple Intermediary sprints are needed then it is OK to connect them one after another but with explicitly approved plan on how many such sprints will exist before the next Release sprint
• Sprint planning time for an Intermediary sprint cannot be longer than 1 day
• Remember that if you have unknowns that are to be clarified during the Intermediary sprint then the sprint plan can be somewhat looser, i.e. Team member 1 Day 1, Team member 2 Day 2, etc. but this is an edge case applicable to time-boxed research only - everything else 

Product release sprints

1) Sprint planning

• Team has two days max to plan out the new sprint
• This is more than enough time for a quick research of goals ahead and a detailed sprint planning
• Take your time for sprint planning, up to several hours for the entire team is sometimes needed and the entire team needs to be present to take part in sprint planning, this is not something a single person (i.e. ScrumMaster) should do
• In case we have more unknowns then the team should not recommend a Release sprint but rather an Intermediary sprint where the primary goals will be to clarify the unknowns through hands-on proof of concept / prototyping or documented plan / deliverable, or to build necessary prerequisites for the eventual release

2) Sprint

• Maximum sprint duration is still 4 weeks or 20 workdays
• Each Release sprint will be divided into two structured wholes: Work phase and Test plan execution phase
• Maximum time allocated for Work phase shouldn't exceed 3 weeks or 15 workdays
• During this time the team should fix bugs, implement features, and complete other general Product Ownership related goals agreed on sprint start
• Work goals should be made in such a way that we can drop off some of the goals during the sprint and still achieve the release: i.e. drop off some of the planned new features, fix less bugs than planned
• If the team doesn't have a Test plan for the product that is up-to-date then one of the work goals needs to be to update the Test plan: this work is owned by the team SA but needs to get a buy-in from the entire team
• Maximum time allocated for Test plan execution shouldn't exceed 1 week or 5 workdays, and should match Test plan execution time estimate in team days
• During this time the entire team will focus on testing the product build in development by following previously prepared Test plan and by splitting test areas among all team members, both developers and SAs
• Test plan execution is "All Hands on Deck" time meaning that no team member is allowed to work on anything other than executing regression test to figure out quality of the current build
• There is no more "inter-team cross-testing" meaning you shouldn't send your build to other teams or other SAs to test it for you
• This doesn't mean that inter-team cooperation isn't allowed - actually it is still a good thing to do cross-testing with other teams especially when other teams are relying on your products and may be affected with the new release
• Devs must still execute "internal cross-testing" and verify each other's bug fixes (i.e. Dev1 tests bug fixes for Dev2, Dev2 for Dev3, Dev3 for Dev1 and final report is sent to SA)
• When the sprint ends the team will figure out how many bugs were found that SA will report in the bug tracker, and will estimate how much actual work remains to release the product
• Not all bugs found are blocking bugs (more on this soon)
• We just need blocking bugs fixed in order to release the product
• At this point the team will know if blocking bugs can be fixed within the Release phase time (see below) or not and will decide one of two things: we are going to release or we need to start a new release sprint in order to fix remaining blocking bugs that will take more than one week's time
• We need to watch out not to begin Release phase if we are uncertain that the remaining blocking bugs can be fixed within the allotted time: it is of no consequence to begin a new Release sprint, but there will be many affected stakeholders if we decide to enter the Release phase and fail to release on time

3) Release phase

• This is instead of what was previously known as "Test phase" but with main difference being that we are no longer spending time to test the product build for the first time but are focusing entire team efforts to release the product
• Release phase can take up to 6 days including the release day which is also considered the first day of the new sprint planning phase
• SAs no longer invest time into test plan or bug prospecting efforts as this is supposed to be already finished during the sprint
• Devs fix only blocking bugs and nothing else
• SAs verify fixed bugs only until we ensure there are no more blocking bugs
• Remember: the ultimate goal is to release a build that is equal or better in quality than the current one in production, nothing more, nothing less