Discovery and Research Sprints?

I believe that if you do that then you will no longer be doing scrum, as you will not be creating at least one done PBI of value, therefore will not have a usable & potentially releasable increment.  

Why not increase your sprint length to 4 weeks and incorporate a spike PBI for research along with at least one PBI of value.  That way you an perform investigative work as well as create an increment of value.

Recently, my company has realized that the Backlog Refinements are not enough to get the teams up to speed on the features we need to work on and delivery during a normal 2-week sprint.

Why not?

They are proposing that we take an entire sprint and only do research, discovery, discussions, diagrams, and design work. We will then re-evaluate by the end of the two weeks if the team can plan for a normal delivery sprint following the discovery sprint. 

Hold on...a so-called "normal delivery Sprint" actually is a Sprint. How can the situation possibly be improved by employing a fake Sprint, which robs everyone of empiricism and the very ability to learn?

A few questions to consider:

• How many products are you supporting? How many Scrum Teams per product?
• How many people support product management, including product managers, business analysts, user experience designers, and similar roles? How are the people doing these functions aligned with the Scrum Teams?
• How much effort is spent on refinement in each Sprint?
• How much of your Product Backlog is refined going into Sprint Planning?

The idea of a Scrum Team not delivering some product change each Sprint and dedicating themselves to "research, discovery, discussions, diagrams, and designs" seems inefficient. There are probably better ways for the people to organize around the discovery and delivery work and make refinement more efficient.

It appears that your company believes a one-month mini-waterfall approach is a solution for all teams. History shows that predictive methods don't work well for building complex products, and is the reason why many choose Scrum. The belief is that if only more rigor is added to upfront planning we'll be more successful. But that rarely works. Changing Scrum most likely won't get your company the change they hope for. 

Others have asked some great questions to ponder. Other questions to think through:

• Has a Retrospective with the Scrum Teams been facilitated to get their ideas on how to solve this? Are you using bottoms-up knowledge of the teams or is this a top-down decision? 
• If mistakes are showing up downstream, how robust is the Definition of Done?
• If multiple Scrum Teams are working on one product, has integration been factored into the Definition of Done?
• Can work be broken down into smaller experiments to limit some of this downstream risk?
• Are the Developers self-managing and deciding what can be completed in a Sprint during Sprint Planning. If they are not meeting their Sprint Goal and completing a Done Increment by the end of the Sprint, do they discuss this during the Sprint Retrospective and try to employ new improvements for the next Sprint?

Every time this has come up in companies where I work it has always resulted in the same thing.  Execs require us to do a "planning sprint".  We do the sprint.  Nothing changes.  Why?  Because while we are taking the 2 weeks for the planning sprint, the executives are changing their minds on what "we should be working on" and we wasted 2 weeks refining the wrong things.  

This is often a problem because the organization is not willing to change the command/control at the upper levels and let the Product Owner be responsible for the decisions related to product direction and needs. Sure, Scrum is useful to help organizations adapt to changes in direction and need but it still requires some level of continuity in order to be effective.  

As others have said, has anyone talked to the teams doing the work to understand what they feel is causing the problem?  Or is this something that the executives feel is a problem so they are dictating a solution to their perceived problems.

Thank you, All! So this is a top down decision that I don’t agree with. Basically, we have 1 Product Manager, 4 Devs, and 2 QA team members on each scrum team, working on various complex features (in various areas of an extremely complex software application). Therefore, the learning curve is steep and takes time. The team refines, we plan, and then something always happens where a feature wasn’t researched enough or thought through enough prior to coding and it requires re-work or takes way way longer than originally planned for. This happens frequently. This is why leadership wants us to just focus on the research and discovery first and foremost. I hate the idea of not delivering a valuable increment. Maybe we could try dual track where we do deep discovery work for a few days, but time-box it and then code it so we’re still delivering value? Basically we have young teams that sometimes don’t do the critical thinking part of their jobs...they just want to jump in and start the work.

@Thomas Owens We have 1 hour of Backlog Refinement each week. We’ve probably refined a 10th of the backlog. PM’s have no support currently and they work very closely with the teams.

This was also prompted because the scrum teams are feeling burnt out, always sprinting, and they need more training and more refinement discussions. Features tend to get rejected at code review. 

I suggest taking a step back and understand/validate what the actual need is. Maybe its just "the organization expects better predictability" or something like that. Then ask yourself / your team: How might we achieve that? And start brainstorming.

Maybe it will be better story slicing, maybe switching to a better estimation method. Maybe more focus on tech debt. 

I am a keen advocate of dual or triple-track agile in other words, continuous discovery. For the sake of customer-centricity, I think it is best to do customer research and validate findings in drips ie in iterations rather than the big burst discovery approach supported by refinement and planning. 

Discovery and Research sprint provides the opportunity for innovation ie the creation of prototypes,  MVPs, and experiment designs.  Imagine a world where developers are given a seat at the table where they can interact with users/customers!!  Sometimes, refinements and sprint planning might not be enough.  It's about building the right product and building the product right