Strategic Vision and Scrum: Looking Beyond the Next Sprint. Jimi Fosdick Certified Scrum Trainer and Scrum Mentor

Transcription

1 Strategic Vision and Scrum: Looking Beyond the Next Sprint Jimi Fosdick Certified Scrum Trainer and Scrum Mentor

2 Abstract When organizations adopt an agile approach like Scrum to product development oftentimes there is so much focus on the iterative nature of agile development that long range vision and strategic product design can get lost. In fact, it is critical that projects include long term product vision from the start, and that the iterations are designed to specifically support that vision. This long range planning should include elements such as user experience and user centered design and to ensure that the result is one that delights the users and at the same time, maximizes an organization s return on investment. It is critical that projects include long term product vision from the start. TABLE OF CONTENTS Planning in Scrum... 3 The 5 Level Planning Model... 3 The Vision... 3 Story Mapping... 5 Clarifying the Vision: The Elements of User Experience... 6 Putting It Together... 7 The Walking Skeleton... 7 Summary

3 PLANNING IN SCRUM Some think that planning in Scrum is myopic because it focuses on a relatively short planning horizon. The critique does in fact have some validity. Normally, Scrum is focused on three relatively short-term planning horizons: 1. A daily planning horizon (the daily stand-up) 2. A two to four week planning horizon (the sprint) 3. The release planning horizon (The next release) The benefits of these three horizons are that they help keep the product owner and team focused on what they re doing. However, they tend to be quite tactical and do not provide a broader, more strategic view, which could ultimately result in problems with the architecture and overall user experience. THE 5 LEVEL PLANNING MODEL Using a 5 Level Planning Model, additional planning horizons are added to address the lack of a strategic view. In addition to the three Scrum planning levels (Daily, Sprint and Release) two upper level planning horizons are added the Vision and the Product Roadmap. Graphic One: 5 Level Planning Onion If I d only listened to my customers, I d just be building faster horses. - Henry Ford The Vision All product planning should begin with the Vision. The product vision is the responsibility of the Product Owner and is derived from work with many stakeholders and users to define the vision for the product or portfolio of products. A vision should answer a number of important questions, the key ones outlined here: 1. Who are the primary users of the product? At the outset the primary users of the new product must be identified. These users are often referred to as user personas. With the idea of user personas, the team can identify different user types within a targeted demographic, as well as specific attitudes and/or behavior sets that might use product in a similar way. Personas are a tool technologists use to segment their target user base. In Scrum-based software engineering, user stories are used to describe the requirements of different personas. User stories focus on outcomes vs. outputs and are typically constructed in the following way: As a <persona> I need to <activity> so that I <outcome>. 3

4 Using user stories, the requirements of different personas are captured in a common way. From the larger set of personas, it is important to then build a prioritized list, with the top priority being the persona that will derive the most benefit from the product. By identifying the key user(s) and focusing on their needs, the software development team can maximize return on investment. 2. What do users say they need? The software development team needs to understand what the primary users need to accomplish. It is important that the product development team hear what users have to say in this regard, rather than to assume that the answer is known. This is an area where it is often helpful to have user experience experts and business analysts involved, as they often help facilitate these conversations. It is also important to have team members involved so that they can hear directly what stakeholders and users say they need. 3. What are their unrecognized needs? Some of the world s most successful companies have achieved their success not by delivering to users what they are asking for, but rather on their delivering on unrecognized needs. Henry Ford said, If I had only listened to my customers, I d just be building faster horses. Technology professionals and human factors people often know things that users don t. They will need to identify what their users might need that they don t even know is possible. Noriaki Kano called these Exciters. They are features that users do not miss if they are absent, but that excite them when they are there. Such features often become indispensable in the future. These are the things that build significant competitive differentiation. 4. What is the simplest possible thing that will delight the users? The 80/20 rule in software holds that 80% of a system s value comes from only 20% of its features. An impact of this is that software products tend to be much more complicated than required. In addition to determining what users need, software development teams must identify things that users say they need, but really do not. The goal is to build the simplest thing possible. In effect, development teams delight more by offering less. A simple, elegant design with high-value features that meet unrecognized needs will delight people far more than a feature-rich product with a long learning curve. Google is one of the most successful software companies, having largely achieved that by delivering one of the simplest user interfaces imaginable and focusing on speed and accuracy of their searches. As a software engineering project kicks off, it is often helpful to put these questions up on a wall and to discuss them with users and stakeholders in a live, collaborative session. This is referred to as a pre-game in Scrum. From these ideas, a coherent product vision is distilled. One popular method for doing this is by creating an elevator pitch, which provides a concise vision of what the product will be, what the organization is trying to do and how it will make the world different. The Product Roadmap The product roadmap is based on the product vision and defines how and when the things that deliver the highest value for the primary target users will be delivered. A useful way to present a roadmap is to identify and prioritize users and needs by quarter. The first quarter should target the users and needs that deliver the highest total return, the second quarter the next highest value, the third quarter the next highest value add and so forth. Ideally this plan sketches the roadmap out for 6 quarters (or more), where the quarters further out becomes less and less precise. This is not a detailed budget plan or listing of activities that people are going to do. Rather, it is a vision for who the team is working to delight, how they will be delighted and when. The product roadmap constitutes the boundary between strategy and scrum. 4

5 Graphic 2: Quarterly Product Roadmap Once the roadmap is established, product owners can begin to build the product backlog. The product backlog in Scrum is a prioritized list of features and functionality that provides value to users and stakeholders and is delivered in an incremental fashion. Story Mapping Product backlogs have one notorious shortcoming when we talk about scrum out of the box. Jeff Patton, a product owner and thought leader in the Agile community, summarized it as follows: A prioritized user story backlog helps to understand what to do next, but is a difficult tool for understanding what your whole system is intended to do. To address this shortcoming, Patton developed the idea of Story Maps which provide a way to create a coherent larger vision from which a good user story backlog can be built. A story map does a number of things: It arranges user stories into a model that helps explain the overall functionality of the system, it identifies the holes and omissions in the backlog, and it provides a larger view that cannot be seen when the team is focused only on what it is doing in the next two to four weeks. A simple way to create a story map is with sticky notes posted on a wall. Once the primary users and goals are identified, the activities they need to perform to have a minimally useful system are determined. In product development this is referred to as the minimum viable product, or MVP. The MVP is that collection of activities that, at a minimum, will provide a potentially shippable product and allow the organization to achieve a return on investment. These essential activities form what is called the backbone of the system. The backbone also represents the spine of the story map. For those familiar with the concept of user stories, these activities can be considered epics and represent the broad areas needed in the system. Since they are all necessary, it does not make sense for the Product Owner to prioritize them. For example, if the team was building an airplane it would not make sense to prioritize the wings, engine, transmission or wheels. The backbone is intended to give an idea of what the team is trying to do, but doesn t dictate specific solutions or implementations. Each of the activities within the backbone can be broken into a number of tasks, and each task can be further broken down into sub tasks. If the team is aiming for the simplest thing that will possibly work they could minimize the number of tasks within each activity. Alternatively, if the goal is to create a system that is feature rich, the task breakdown may be more elaborate. Noriaki Kano s model of customer satisfaction involves the idea of Exciters. Exciters are features that users do not miss if they are absent, but that excite them if they are there. 5

6 Graphic Three: The Story Map Clarifying the Vision: The Elements of User Experience Many of the concepts around Story Maps come from the world of user experience. User experience (UX) engineers are often left out of Scrum teams. As such, they can have a tendency to work in more of a waterfall fashion, building a completely detailed UX flow through all layers of the UX stack and then handing that off to Scrum teams. This is not effective. UX people need to be integrated into the Scrum process. To understand how this can best be accomplished, it is important to understand UX. In his book The Elements of User Experience, Jesse Garrett, author and thought leader in the UX space, describes user experience through a number of layers called the User Experience Stack. Graphic Four: The User Experience Stack The layers in the UX Stack go from the most abstract at the bottom to the most concrete at the top, and are: Strategy, Scope, Structure, Skeleton, and Surface. 1. Strategy: The most abstract, lowest level of the stack is strategy. Strategy is where it all begins. Defining user goals, requirements, and context. 2. Scope: The next step is to transform that strategy layer into requirements and defines what features the product needs to include. Scope encompasses the activities and tasks for achieving the goals and translating the user higher needs into features. 3. Structure: Once the Scope is determined, the next step is to develop the script structure which gives shape to what is being built and describes how everything will stick together. Team should think of the user experience flow, which might be a series of flow charts that describe how a user navigates through the system. 4. Skeleton: The skeleton makes the structure complete and consists of the components that enable people to use the site. Often this includes wire frames that lay out the basic elements of the product UX that allow the user to perform an activity or navigate through the system. 6

7 5. Surface: The most concrete of the layers, Surface brings everything together visually. It describes what the product will look like. This may include design elements like color palettes as well as the graphical elements that will be used. PUTTING IT TOGETHER Initially the focus should be on fleshing out the strategy and scope before moving to the next three layers. These three layers, structure, skeleton and surface, are referred to as the Emergent Design layers and focus on what the finished product will look like. Similar to the first two layers, they are fleshed out just enough and then modified incrementally. As the team iterates through each sprint, they build increments of the entire system, and continue to build out the structure, skeleton and surface. These increments will have an impact on scope and strategy, and as a result the layers below are constantly being revised to support the layers above. This process enables the product to emerge from the vision, and change over time. The Walking Skeleton The walking skeleton is a term used to describe the backbone of activities and corresponding tasks that are required to be considered a viable product. The walking skeleton is a feature poor, minimally scoped version of the final product. It does not do everything it will ultimately be required to do, but it is something that will minimally meet the needs of the users. It is important to create the walking skeleton as early on in the project as possible, because it defines how the underlying architecture works. Remaining work will be added later in a prioritized order, as refined functionality. The walking skeleton provides users and stakeholders a way to interact with the system being built, and helps the team validate the vision, identify gaps, and clarify the backlog. Once the walking skeleton is built, the goal is to keep it walking. Alistair Cockburn, one of the signatories of the Agile manifesto, describes a walking skeleton from an architectural perspective on his website ( A walking skeleton is a tiny implementation of the system that performs a small end-to-end function. It need not use the final architecture, but it should link together the main architectural components. The architecture and the functionality can then evolve in parallel. This means that once the architectural elements are connected and the system is able to handle simple functions, additional functionality can be developed and added in parallel with the architecture revisions, all while keeping the system working and robust. The walking skeleton helps teams make architecture decisions based on what has actually been observed that the system is doing and supports the agile, iterative approach to doing things. What constitutes a walking skeleton varies with the system being designed. For a client-server system, it is a single screen-to-database-and-back capability. For a multi-tier or multi-platform system, it is a working connection between the tiers or platforms. For a compiler, it might consist of a compilation of the simplest element of the language, possibly just a single token. For a business process, it may be a single and simple business transaction. The point is that each subsystem is still incomplete, but they are hooked together, and will stay hooked together, from this point on. It may not support every activity that we have identified as important, but the walking skeleton will help allow the architecture design and additional features to emerge over time. There is a phrase that is popular in agile engineering, Don t overdrive your headlights. This means that development teams should limit their detailed implementation decisions to only the next few sprints. Otherwise, decisions will be made that are based on information that is not yet available. In a traditional approach, most decisions are made upfront as the team conducts formalized requirements gathering and analysis, builds out a full design and plans the product architecture. One of the underlying principles of Agile and Scrum is to delay decisions until they need to be made, when more and possibly better information is available. In this way, important decisions are made with the best information available, including feedback from users on product iterations. By adopting this emergent approach to architecture and design, the agile team avoids painting themselves into a corner where architecture re-work is expensive and time consuming. 7

8 SUMMARY Agile generally, and Scrum in particular, is a highly effective way to build software. To maximize that effectiveness and ultimately delight the users, long range planning must be an integral part of the process. The normal three planning horizons in Scrum (daily stand up, sprint and release) should be augmented with an overarching product vision and a long range release roadmap that will help to guide all of the development activities. Employing models like the user experience stack, story mapping, and the walking skeleton, enable teams to take an incremental approach to architecture design which provides more flexibility, eliminates rework, and increases an organization s return on investment. CollabNet has a decade of experience training and coaching hundreds of organizations worldwide, and offers a comprehensive portfolio of Agile training, coaching and software tools. Working with a competent facilitator who understands Agile planning and best practices is the best way for organizations to delight their users and make their agile implementations most successful. For more information, contact [email protected]. 8

9 ABOUT THE AUTHOR As a Certified Scrum Trainer with CollabNet, Jimi Fosdick has conducted hundreds of Agile Training courses around the world, helping organizations improve their development processes using Scrum and Agile techniques. His 15+ years of experience in software product development spans a wide range of industries, in both the private and public sectors. Jimi is a PMI-certified PMP and received his MBA in project management from Keller Graduate School of Management in Chicago. As an undergraduate, he studied mathematics and computer science at Loyola University in Chicago. For more of Jimi Fosdick s thoughts on Scrum, visit his blog at: ABOUT COLLABNET CollabNet is the recognized leader in enterprise Cloud development, powering global software development for more than 7,000 companies, from workgroups to enterprises. As the company that spawned from deep open source roots with the sponsoring of industry-leading Subversion, we are dedicated to leveraging collaboration, Agile methods, and Cloud computing to transform the way software development organizations develop and deploy applications, in their cloud or ours. Through this transformation, CollabNet clients have recognized improved productivity by up to 70 percent and reduced their cost of software development by up to 80 percent due to the implementation of highly Agile and enterprise-wide collaborative and distributed techniques. Our solutions include TeamForge, the industry-leading Agile ALM platform for distributed developers, ScrumWorks Pro Agile project management, Subversion Edge for managed SCM, and Agile training and transformation services. For more information, please visit CollabNet, Inc. All rights reserved. CollabNet is a trademark or registered trademark of CollabNet Inc., in the US and other countries. All other trademarks, brand names, or product names belong to their respective holders