Impact-Driven Scrum Delivery

Ingrid Domingues, @ingriddomingues, InUse, https://www.inuse.se/

Impact-Driven Scrum Delivery brings together Scrum's capacity to deliver working software, with the ability of Impact Management to define actionable metrics, and to evaluate outcomes well before the production of working software. The idea of "outcome over output" [1], lately emphasised in the Agile community [2], can now be realised in all types of projects - not only those where it is feasible to do the measuring by releasing the proposed new solution to a small percentage of real-time users. Finally, Impact-Driven Scrum Delivery solves "the Product Owner's dilemma" [3], and makes the management ideal of "pivot or persevere" [4] an inherent capability of the process.

Impact-Driven Scrum Delivery starts with the insight that, from a business perspective, design matters a lot. This doesn't mean that a bad business idea, or badly-understood user needs, could be covered up with design, but rather that a good business idea and understanding of user needs will suffer from bad design. I mean "design" as in "designing the digital solution", which involves everything from visuals, interaction, content, response time, metadata, performance, to maintainability and all back-end capabilities.

First, Impact-Driven Scrum Delivery addresses solutions with user interfaces. Then we state that - in order for the business to gain what is expected from the investment in this digital solution - the user must succeed. Therefore, the delivery process starts and ends with the user's activities. Understanding needs and behaviours, defining actionable metrics [5], designing user interfaces that support and satisfy users and measuring the activities that indicate business success: these are the essence of this process.

Impact Management is a framework that helps managers to keep focus on impact from idea to continuous improvement. Impact Management originated from a paper [6], From Business to Buttons, which defined the concept of Impact Mapping: the ability to define expected impact for business and users in a model, in such a way that it can be evaluated and measured at any specified time. Impact Mapping evolved into the framework of Impact Management [7], which gives business and project managers the ability to maintain and act upon an impact focus in their software development program or project.

The Impact Map describes the business and user values that a new product or service is expected to generate. It has a straightforward structure, similar to Simon Sinek's "golden circle" [8], describing

• why this solution is a good investment for the business
• how people are going to gain from it
• what the solution should encompass in order to promote user satisfaction and business prosperity.

Impact Mapping and Management caught on fast and are today widely used within software development. Impact Mapping crossed over into Agile software delivery at the start of the decade. [9] An Impact Map can be used to formulate an idea without doing a lot of analysis. But if the Impact Map is to be used for Impact Management it needs to be grounded in analysis that can explain the causality between user needs and business impact. Such Impact Maps are furnished with clear description and priority of user needs and user behaviours, as well as actionable descriptions of business and user needs, which can be employed for testing solutions at any specified time. The need for established user studies and analysis of business opportunities increases in proportion to complexity, such as projects with many stakeholders, more severe risks of being wrong and less freedom for continuous testing [10].

When Impact Management meets Scrum, Impact-Driven Scrum Delivery is born. This solves the Product Owner's dilemma, enhances the communication from business to the team, and makes teams deliver outcome over output. Impact-Driven Scrum Delivery provides a strong framework for continuous communication between two perspectives: business and delivery. The business side is responsible for the outcome, ensuring we build the right thing, whereas the delivery side is responsible for building the solution in the right way. Scrum provides a perfect communication platform where these two perspectives can meet. Impact Management gives a clear purpose and means for measuring success. Impact-Driven Scrum Delivery marries the two, and helps both perspectives perform better, with autonomy, mastery and purpose [11].

Impact-Driven Scrum Delivery solves the Product Owner's dilemma. Product Owners understand that design matters and that user interface design is crucial in order to meet expected business benefits from the digital investment. But very few Product Owners have the skills necessary for user interface design, neither on a concept level nor on a detail level. At the same time, the Product Owner has the responsibility to deliver value to business with the product that is built and shipped. Usually there is also more than one business stakeholder for any product. This means that the Product Owner has to spend time (sometimes a lot of time) to explain the solution, negotiate scope, capabilities and outcome with other stakeholders within the company.

Add to this the team's need to get instant answers to detail questions. Thus, the Product Owner's dilemma is that he or she lacks the design skills needed to really provide the support the team needs. Product Owner needs to spend his or her time in communicating with the other business stakeholders to ensure the right business decisions are made, and to prepare all involved parties for action when needed.

Impact-Driven Scrum Delivery strengthens the business side of a Scrum project with a User Experience (UX) Lead. A UX Lead is an experienced UX designer, someone who has worked with designing different products for some years, and has therefore built a genuine understanding of the way design can strengthen business. He or she has a broad set of tools for understanding user needs, testing outcome, visualising flows and customer experiences, defining MVPs [12] and doing user testing. A UX Lead also has a profound understanding of how different user interface designs affect data and coding, how business rules must be defined to boost user experience, and so forth.

The UX Lead is the Product Owner proxy, giving the power to the Product Owner to fulfil his or her business responsibility, and leaving the UX Lead to manage the day-to-day Product Owner work. UX Lead and Product Owner start their work with defining expected business impact, understanding user needs, and designing and testing - from a business perspective - the most important flows.

This starts before the Scrum process, and by terming it "sprint minus 1" we remind people that it is a necessary antecedent to "sprint 0". Exploring business opportunities and needs, understanding user behaviours and defining actionable metrics can be swift, but more usually it takes time: not only making the discoveries, but also understanding the business implications of all the opportunities revealed, and agreeing which alternatives to move on with. This is, of course, more difficult in more consensus-focused cultures, and easier in cultures where decision-making is simple. During "sprint minus 1" the following happens:

• The UX Lead works with the Product Owner to define expected impact, by analysing user needs and business opportunities, and boils these down to actionable user goals and business impact. This results in an Impact Map where there is a causal relation between user activities/success and expected business impact. In charting this causality the Impact Map also defines what the user needs in order to feel satisfied, touching on the capabilities or functions that will satisfy their needs, and ways of evaluating their satisfaction.
• The UX Lead also works in a structured "design thinking" way to find patterns for interaction, form and content that have been verified in a working prototype. "Design thinking" in this sense means work structured with divergence and convergence [13]. If possible, simple user tests are performed, and the goal is to verify assumptions about how the expected impact for user and business will arise. The design process strengthens the quality of the Impact Map, detailing how to measure success. Having a solid foundation for user interface architecture also gives excellent ground for detailing user stories with acceptance criteria, such as user interface details including function, form and content
• When the project is a matter of enhancing something that already exists in working systems architecture, the prototype will be treated either as an MVP in "sprint minus 1" or it will be the first shippable increment
• In projects with very limited budget the prototype can be very rough. The point is still to explore the best way to make users succeed with the most important user flows, which could sometimes be tested with simple PowerPoint prototypes
• Equipped with such a well-grounded Impact Map, the Product Owner, UX Lead and a systems architect create the first suggestion for roadmap and product backlog. The stories in the backlog will be tagged with user, and user goals, among more standard labels such as epic, increment etc.

Here is where the so-called "sprint 0" starts, where the Scrum team and process are set. When using Impact-Driven Scrum Delivery, some amendments will need to be agreed upon:

• The UX Lead is responsible for any user-interface design-related questions. He or she will be available to the team all the time, and will respond instantly
• The UX Lead has direct and daily contact with the Product Owner in order to discuss any business-related issue. The Product Owner has full responsibility for business impact and anything that can affect the business outcome. The Product Owner therefore owns the product backlog, and is the only role authorised to perform prioritisation. Usually he or she delegates the operational maintenance of the backlog to the UX Lead
• The UX Lead will prepare user stories well ahead in the backlog, to be discussed at backlog refinement meetings, held between sprints. The stories emerge from the Impact Map, refined and described with a user-interface design and user acceptance criteria. In the discussion, the team will add insights of opportunities and obstacles. Sometimes one story needs to be discussed in more than one backlog refinement meeting, in order to make user needs, good user interface and service design meet what is a good way of coding and developing the solution. The stories need care and consideration from the team, so that all can agree that the suggested solution is feasible and practical to build and maintain.
• The UX Lead is thus responsible for ensuring that all stories that reach sprint planning are well-worded and prepared. The UX Lead is responsible for refining the story when it is discussed in the sprint planning meeting and checking that acceptance criteria also meet the needs of the user interface. The UX Lead is responsible for including a visual description of any design details not laid out in the prototype
• In "definition of done", an interaction review is added for every story with a user interface. This means that the UX Lead should be consulted before marking the story as "done". This will radically reduce the UX guilt for the team
• The UX Lead is responsible for evaluating, and validating, the extent to which shippable increments meet user needs, and create expected impact. This can be accomplished in different ways. Sometimes it is appropriate to do testing in sprints, but more often user testing is treated as a separate swimlane. It is a good idea to integrate user testing into the team work in an orderly way, so that team members have time to participate in some test occasions.

Our experience of this way of working is extremely promising. It gives the team the potential to deliver at its best. The team knows that its priorities are clear. They are given full support in any design issue and they know that shippable increments have undergone user testing. This results in high-quality solutions, it resolves the Product Owner's dilemma and it delivers in software that provides expected impact for business and users.

References

1. https://hbr.org/2012/11/its-not-just-semantics-managing-outcomes
2. Eg in Jeff Patton's latest book, User Story Mapping
3. Lightning talk about the Product Owner's dilemma http://www.slideshare.net/inusese/the-product-owners-dilemma-and-how-to-solve-it-2012-0417
4. Eric Reis, Lean startup http://www.entrepreneur.com/article/220302
5. http://fourhourworkweek.com/2009/05/19/vanity-metrics-vs-actionable-metrics/
6. https://www.designsociety.org/publication/29623/from_business_to_buttons
7. Published in the book Effektstyrning av IT (in Swedish, Liber 2004), published in English as Effect Managing IT (Copenhagen Business School Press, 2007, out of print)
8. Simon Sinek explains the golden circle
9. The Agile delivery aspect of Impact Mapping was described by Gojko Adzic in the 2012 book Impact Mapping, recently translated into Chinese and Japanese.
10. The manner in which different project conditions affect ease of impact management is further discussed in the article Getting the Most out of Impact Mapping
11. Dan Pink explains what people need in order to be motivated
12. Minimum Viable Product, usually defined as "that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort." This is one of the key principles in Lean Startup Methodology. Recommended reading, Cindy Alvarez: Lean Customer Development.
13. http://en.wikipedia.org/wiki/Design_thinking#Divergent_thinking_versus_convergent_thinking

Related Agile and Scrum articles

Analysis on Analysts in Agile

The UX Runway: Integrating UX, Lean and Scrum Cohesively

Creating an ATDD Ready Sprint Backlog in Scrum

Agile, Scrum and Project Management Resources

Scrum Expert

Project Management Planet

Click here to view the complete list of archived articles

This article was originally published in the Spring 2015 issue of Methods & Tools