The Scaled Agile Framework (SAFe) recommends an Innovation & Planning Iteration, often called the IP Sprint. The practice isn’t completely unique to SAFe, but it’s an important part of the framework. The IP Sprint is when planning and preparations for the upcoming Program Increment (PI) occurs, and it helps build predictability for PI commitments serving as an estimation buffer for anything that had to spill over. Once a team’s PI commitments have been met, the IP Sprint is a great time to see some extra magic emerge. Instead of just delivering the value that others have envisioned, teams are empowered to build the value that they’ve envisioned.
It’s a great practice, but as important to SAFe as the IP Sprint is, I still hear some common questions and misconceptions. So I’ve put together the following FAQs.
How can we trust the teams to use this time wisely?
This question indicates a lack of trust in either the character or the capabilities of the team members. I hear this so often, and in my more brazen moments I respond directly: “Why would you hire people that you don’t trust?” Although said with a smile, it points to the root issue. In this situation, I believe the best way to build trust is to become vulnerable and extend some trust: give the teams a chance to prove they are the competent professionals we thought we hired. I have yet to be disappointed in how teams steward this responsibility. Often, they choose to do something that is very much needed and would otherwise remain hidden until it became a problem.
Isn’t this just supposed to be a tech sprint?
It’s not a tech or engineering sprint; it’s an Innovation and Planning (IP) sprint. It is when both the Inspect & Adapt (I&A) and PI Planning occurs. It serves as a buffer for teams that have not already met their PI Commitment and helps build predictability in the PI Objectives. Assuming teams can meet their commitment prior to the IP Sprint, the developers pick activities that they believe will add value.
Does the Product Owner need to be involved in the IP Sprint?
Why wouldn’t they be? Do you want them to feel like they are part of the team? What are some ways that they can enhance the IP Sprint by their participation while also (1) maintaining focus on the finishing the PI well and (2) preparing for the next PI? SMs, POs and Dev Teams should talk to make sure everyone’s voice is heard on how to approach the IP Sprint and make the best use of this time.
Do we need to do all that “Scrum Stuff” during the IP Sprint?
Why would you NOT use the same rigor? There may be a reason, but for teams new to SAFe (e.g. – Agile Team has been practicing SAFe for less than 3 PIs) I don’t recommend trying something new; seek to improve upon the ScrumXP or Kanban practices already being applied. There may be good reasons for more mature teams to try something different. However, they will still want to apply an empirical rigor to what they attempt in the IP Sprint: enter the Iteration with a hypothesis for what will happen if you do something differently, then evaluate that hypothesis in the retrospective and determine how to respond.
What do teams do differently during this sprint from any other iteration?
Developers may choose to refactor code, develop the next killer app for their company, remove tech debt, or explore a new way of doing something.
It can be a good time to upgrade skills with formal training, exploration enablers and process improvements. For example, the team may want to take an innovative idea and implement it while experimenting with mob programming. Or maybe it’s a good opportunity to build T-shaped skills within the team.
How Can the Team Use the IP Sprint to Upgrade Skills?
Continue to apply the same rigor in the IP Sprint as with any other Sprint. Be sure to understand the value of the activity and use clear acceptance criteria that creates something demonstrable. You can’t demonstrate that you’ve read 5 chapters in a book, but you can tie the knowledge to something concrete. For example, you could present the applicability of a technology or practice for future initiatives. You could also prototype using a new language or tech stack, or you could summarize findings in a white paper. Product Owners should help the teams develop User Stories that explain the value of what they are doing. Scrum Masters should challenge the team to make it tangible / demonstrable / practical — and not just an abstract exercise.
What else should the team consider?
- Teams will want to adjust their Sprint commitment to adjust for the additional Program Level ceremonies.
- Developers should write stories that describe what they want to accomplish (User Story Voice including value statement and clear acceptance criteria), and they should approach it with the same level of rigor as any other iteration, including the communication of IP Sprint accomplishments. Otherwise the perception will grow that the IP Sprint is a non-productive period.
- Consider how and when to communicate the accomplishments of the IP Sprint. Even better, consider how to celebrate the accomplishments and leverage the innovations so it never feels like throw-away work.
Ultimately the IP Sprint is a time to catch up, clean up and move up. Do it well and leadership won’t question why you’re doing it. Instead, they’ll wonder how they ever survived a rapidly changing business environment without an Innovation and Planning Iteration.
