By Tobi DeVito
Agile scrum teams adhere to specific ceremony and guidelines, starting with Sprint 1. However, any successful team—from product developers and stakeholders to executive sponsors—knows that there’s a common beacon: a Product Vision. Before a Sprint 1, teams need to invest time in a Sprint 0, where establishing a Product Vision is one of the main goals. And, while not many will argue against the necessity of establishing a Product Vision, I have encountered my fair share of Sprint 0 haters.
Most visceral reactions to Sprint 0 (the term I prefer to use for the work an Agile scrum team completes prior to the first day of Sprint 1) are from die-hards that hold tightly to the self-organizing, autonomous, non-hierarchical principles of Agile. They tend to believe all work on a product starts with Sprint 1, including work required by teams to come up with a Product Vision.
But, at the very start of Sprint 1, scrum teams must be properly armed to measure their progress with velocity. For those who slept through Physics, velocity is speed and direction.
Speed drives much of an Agile scrum team to quickly iterate toward workable prototypes. But, all of that is naught in the absence of a Product Vision, or direction.
A Product Vision allows teams to align on user needs, technology-driven capabilities and business requirements—instilling confidence on the very first day of Sprint 1.
When created, documented and agreed upon equally by all parties, the Vision establishes a foundation and common understanding of the purpose of the work by answering the following question:Design Thinking can be an accelerator to crafting a Product Vision. Begin with gaining a thorough understanding of the problem through observation-based insights (Why? and, For whom?). Then, brainstorm ideas about what is going to be built (What?). The inputs from these first two steps are then used to set an initial plan (How?).
While volumes have been written on Design Thinking techniques and methodologies, the following is a highlight of those exercises and approaches I have seen teams use successfully when developing a Product Vision during Sprint 0.
Step 1: Understand
Design Thinking begins with establishing a common agreement of the problem between all involved: stakeholders, product teams and executive sponsors. Teams conduct user interviews, research and discovery to drive consensus on the full breadth of the issue, including the business objectives and target audience.
Business objectives explain why the stakeholders are investing in solving this problem for their target audience, and why they are choosing to do so now. They also articulate what a successful outcome of the solution could look like. All objectives should be:
In addition to understanding why a solution is being built, teams must identify the target users and understand their needs. Building an empathy map will help define the solution personas and put the team in the users’ shoes, ultimately positioning the user at the center of the development process. Stakeholders and product teams alike will internalize user pain points, which will allow them to more effectively identify and prioritize product features and requirements in the Product Roadmap.
Step 2: Ideate
With both business objectives and user personas defined, the second step of a Design Thinking-infused Sprint 0 is to envision what the solution must accomplish to meet the users’ needs—in other words, the solution objectives. In addition, teams can begin to concept what the solution might start to look like.
While there are many brainstorming methods, in my experience there is no replacement for a good old-fashioned in-person worksession. There’s something about Sharpies, sticky notes, painters’ tape and donuts that really gets the creative juices flowing. That said, I have also seen remote workshops serve as a decent replacement, especially with the litany of collaborative software out there today (e.g., Zoom, WebEx, Mural, Trello, Jira, Slack, Google Docs).
Regardless of the medium or exercise, teams should work together during this phase to answer the question:
With criteria established, teams can begin to ideate on what the solution itself will look like. They can identify high-level features and/or the potential architecture of the solution. This includes defining frameworks, platforms, data models, tech stacks and QA/test environments and processes.
Step 3: Plan
The last piece of this Product Vision puzzle is the plan that the team will follow to make the vision a reality, the Product Roadmap.
The Roadmap defines, groups and prioritizes the capabilities the team will build in the solution to meet users’ needs. Capabilities should roll up to the solution objectives and be in support of the larger business goals. They can be grouped in any way that makes sense for the team (e.g., product components, themes or solution objectives).
However, the groupings themselves should not be prioritized. A Most Viable Product (MVP) is not achieved by building every capability in a single group—such as the entire messaging platform or the full reporting module. Rather, as your team begins to build the Product Roadmap, they should prioritize capabilities across groups, identifying the highest priority for the MVP—for example, a single instance two-way dialogue box or one type of report at initial launch.
Sprint 1 and beyond
The Roadmap should be established before any work begins, and be in service of the agreed-upon Product Vision. The Roadmap should also be allowed to grow and change to meet the demands of its users through each release.
Following this Design Thinking methodology in Sprint 0, teams should be ready to hit the ground running.
As Director, Technology and Product Management Tobi’s career has spanned a variety of disciplines and industries—from leading digital product teams for Fortune 100 clients and executing multi-million dollar media campaigns for leading e-comm retailers, to building CRM databases for national non-profits. At VSA, Tobi delivers bleeding-edge digital experiences for IBM, leveraging Watson and other IBM Cloud and cognitive technologies. Through her broad experience, Tobi has developed the critical skill of nurturing, motivating and empowering teams. In unifying internal and external stakeholders with clearly defined product vision, requirements and purpose, her teams have consistently delivered differentiated, user-centered products across varied platforms, services and tech stacks. Tobi is a Certified Scrum Product Owner and holds a Bachelor’s degree in Philosophy from University of Puget Sound and a Master’s degree in Public Administration from New York University.
Tobi can be contacted at firstname.lastname@example.org