Blog Product Workshops Event storming or product vision? Discover workshops that will help to build your next appEvent storming or product vision? Discover workshops that will help to build your next app
The much-quoted phrase, “If the only tool you have is a hammer, everything starts to look like a nail“ (first coined by Abraham Maslow) carries an obvious truth for software development: if each project is different (in our experience, it is!) then you’re going to need as many tools as you can get. When it comes to planning, we find that workshops are a great way to bring dev teams and stakeholders together for really practical and constructive results. We’ve looked through our toolkit and picked out some of our favorite workshops. And yes, we conduct most of our workshops entirely online as well!
Table of contents
It’s a fundamental principle of the scrum approach to software development that the final product should fit as exactly as possible the relevant user and business needs. That’s a fairly obvious statement and we doubt anybody would disagree with it but… discovering those needs is easier said than done.
In fact, ‘discovering’ is the right word because usually the full range of needs and factors that should influence the product design is not known. The client has part of the picture. So do the target users. Then there’s the market, the competition and so on.
An initial conversation with the client is just the first step and here at Boldare, building the fullest possible picture of the intended app’s environment is a critical thread in the development process.
How do we do it? Workshops!
We use a variety of different focused workshops as part of our scrum processes, with full client involvement and radical transparency, to identify, analyze and fully understand the factors that will impact the product.
This article gives an overview of the eight main workshop formats in Boldare’s toolkit (although of course, they’re not the only ones we use!). For more detail on any of them, follow the links below.
1. “What is Scrum?” workshops
Scrum is an agile lightweight approach to software development and our main tool in what we do. This first workshop is an ideal primer for clients and partners who are using scrum for the first time or have only limited experience of it. In this workshop**, we cover exactly how scrum…
- …is tailor-made for rapid and efficient software development.
- …involves all the key players, giving maximum visibility to the client.
- …produces a series of product iterations in short, highly-focused periods of work called sprints (at Boldare, usually of one or two weeks’ duration), ensuring regular and rapid progress.
- …is about openness of communication, regular inspection of results as they are produced, and a readiness to change in adaptation to circumstances.
With scrum, each sprint delivers a functioning piece of software, focusing on a specific feature or other element of the larger design. The scrum process contains strong planning elements and anticipation of difficulties or changes before they happen. At any point, scrum enables the direction of the overall project to be easily changed (pivoted) in response to changes in the user or business needs, or other environmental factors.
Using scrum, the results are a quality product, user satisfaction, reduced time to market, faster monetization, and all via a process of enhanced teamwork and collaboration between the involved parties.
2. Product Vision
In essence, the product vision is the overall goal for the software under development. The vision is a description of what the project is aiming to achieve, its raison d’être, so to speak. As such, it is an invaluable reference point throughout the project, keeping the work, the sprints, the iterations, all on track towards this overarching objective. The product vision workshop is at the core of our investigation and information-gathering prior to commencing work on the development of a product with a focus on the problem or need that the product must address.
Key product vision tools used during the workshop include:
- A pre-workshop questionnaire that explores details about the target persona, system roles, competitors, the product’s strengths and weaknesses, the values that it represents, and the image that stakeholders want to present.
- Business model canvas - looking at the needs and goals of the client’s business to provide the bigger picture, going beyond the context of the product.
- Product canvas - asking the key questions in relation to the product, including the target users, its purpose, its goals, and the metrics that will measure success.
- Product vision board - summarizing all the key details for the project, including the vision itself, the target users, the need or problem that the product will solve, and link to the client’s business goals.
Thanks to such tools, the dev team can fully understand what they are developing, and why; giving them the foundation for the rest of the project.
3. Event Storming
An event storming workshop is an ideal way to dig deep into the context of the client’s business, resulting in a detailed picture of the backdrop against which we’re developing a product: the business goals and objectives, people, potential obstacles and bottlenecks, dependencies… basically all the interrelated behaviors and business elements that influence and impact on the product’s design.
Using the workshop methodology originally proposed by Alberto Brandolini, the dev team, Product Owner and relevant stakeholders can produce a complex and nuanced big picture for the project which serves as a touchstone and guide throughout the sprints and product iterations. As a result, the dev team moves forward with a highly detailed set of insights into the client’s business environment which are, in turn, reflected in the end product.
What’s more, event storming’s highly interactive (and high energy) nature makes for a fun workshop environment which also serves as part of the team bonding and getting-to-know-each-other process.
The result of an event storming workshop is a map of the existing business processes. After the workshop, the development team understands the product, its business foundations and the stakeholders’ aims. Knowing what roles, software modules, and use cases are necessary to finish the product, it becomes easier to pursue the mutual goal that must be delivered.
4. System Story
When faced with a mountain of information, sometimes the best thing to do is boil it down to a simple statement. The system story is a single sentence that answers the bottom line questions for your product:
- What are we building?
- How will we achieve the goal?
- Who is it for…?
- … And why?
Sounds simple and it is. But easy, it is not.
Granted, the answers to these questions can also be found via some of the other workshops on this list. But not only is it often handy during a project to have the system story ‘one-liner’ version, the process of exploration and debate necessary to agree on a system story can be essential as the depth of discussion ensures common understanding on all levels between the dev team and the client.
You can conduct System Story workshops (and many others as well!) remotely using our free Sprint Retrospective Tool.
The result of a system story workshop is a clear idea of the bigger picture of what the product is supposed to be, who its target personas are, and the main functionalities and problems it solves for and with them.
5. User Story Mapping
In agile software development terms, a user story is a short description of a desired product feature, from the standpoint of a particular type or class of product user. In project terms, a user story can be defined as the smallest unit of development that provides value to a user; often following a template:
“As a (type of user), I want (feature), so that (benefit to user).”
User story mapping example: As a photography enthusiast, I want to share my photos easily, upload them using a mobile app and let my online followers comment and rate them.
This template has three key elements: the desired feature, the specific type of user that needs it, and the motivation for that need.
The mapping part involves placing the various user stories in an order that reflects how the product will be used. By identifying the users first, and then the feature-related ‘journeys’ of those users as they interact with the product, the priorities for development become clear and in turn inform the content of each agile sprint. In other words, user story mapping can be of great importance as a focused project planning tool.
6. Impact Mapping
Impact mapping is a strategic road mapping technique that we use to get clarity on the route the project work needs to take. Consequently, it has an impact (!) on decisions about which aspects of the planned product, which iterations, are tackled in which sprints.
By focusing on four key aspects – goals, actors, impacts and deliverables – an impact mapping exercise can provide a common focus on project activities and assumptions while keeping the overall business objectives in mind.
The result of impact mapping is software that best serves the business and user needs because everyone involved is working on agreed and aligned priorities. Thanks to an impact mapping workshop, the development team is better able to build a product that closely fits users needs and fulfills the business goals of the stakeholders. It’s a win-win situation.
7. Design thinking
With roots as far back as the 80s, design thinking is a process that enables a ‘designer-consultant’ perspective on a project. Projects that use the design thinking concept tend to achieve their goals more rapidly, reduce their costs, result in a higher quality end product, and give a better return on investment.
While approaches differ, the key factor in design thinking is a clear focus on the client and understanding their context, issues and needs before applying creative problem-solving to identify solutions.
Design thinking is focused on issues such as understanding users, the problem the product is intended to address, idea generation, prototyping and testing. It’s also a ‘community-based’ route to take, stepping away from traditional role-based functional silos to gather the best and most varied thinking on the issue at hand.
Design thinking should be used to solve problems, and not begin with a specific solution in mind.
Thanks to this approach, you can get results that are free of initial assumptions. One example of design thinking in action was when one of our teams had to create a webpage dedicated to services for one of our clients. The team and stakeholders came to the workshops with ideas already in mind about how the website should look and function. However, thanks to the design thinking process, they focused on the crux of the whole problem and revisited whether the user needed this page at all.
As part of the exploration and understanding stage (in design thinking known as “empathise stage”) of the process, they reviewed various data, including the site traffic figures and number of current customer inquiries the website had. They were looking for answers to such questions as:
- Why does the client come to us?
- What words do they use?
- What services are they looking for and what are they called?
It turned out that the site visitors used very simple vocabulary, while the stakeholders prefered to use sophisticated and complicated jargon that could be difficult to understand for potential customers. So, the problem was in users understanding the offer. As a result, the tone and voice of the communication changed, making it easier to understand.
Design thinking is also perfectly suited to use in an agile environment, such as Scrum.
8. Planning poker
Teamwork and collaboration are key to agile software development and one way to build connections within the dev team and between the dev team and client stakeholders is to make the process fun. Hence planning poker, a gamified, Scrum-friendly, consensus-building approach to project estimates. (And if you’re wondering how good a fit planning poker is with scrum software development, the alternate name is Scrum poker!)
What’s being estimated? The effort and time required to achieve individual development activities. Each user story is described and then participants each play a card that indicates their estimate of the time and effort needed (not necessarily a physical card, online versions are easily available).
Each card holds a number, such as 0, 1, 2, 3, 5, 8, 13, 20, 40 (however, values can differ) that stands for the estimated hours, days or number of story points needed to complete the task.
Players of the highest and lowest estimates both explain their assessments and a full group conversation follows. The card game format and materials give structure (and hopefully some sense of fun) and keep things moving, avoiding the ‘process trap’ of overlong debates and discussions.
The conversation is also a useful way to involve everyone in a non-confrontational way, therefore encouraging a wider range of views and insights to be shared, to the ultimate benefit of the planning process.
Planning poker results are reliable estimations that can support the whole or parts or the development process. The main strength of this method is that it gives a chance to discuss particular features with the whole team, giving everyone a chance to see the bigger picture and making it possible to spot bottlenecks and potential blockages early in the process.
Can we conduct workshops online?
Long story short, yes!
We have long experience of handling such workshops online, mainly for our clients in the United States. We connect using Google Hangouts Meet, or Zoom to record the call. For joint work, we use tools like Miro or Boldare’s own Sprint Retrospective Tool - both enable us to work simultaneously with unlimited numbers of users and save the results for later use and reference.
The length, quality and results of our online workshops are the same as those of workshops conducted on-site.
The common threads running through all these workshops are involvement and transparency. All of these workshops can potentially involve all project personnel, from both the developer and business sides. This naturally encourages multiple perspectives which, in turn, offer the broadest possible insights and understanding of the product: what it aims to be, why, and how it will address both the business and user needs.
At Boldare, we use this list of workshops as a menu, choosing the ‘meal’ best-suited to the requirements of each individual, unique project.
Share this article:
