Storymapping / Roadmap Session
Storymapping is a great way to get your new DevOps team up and running. The idea is to start with the end in mind and try to design the product end-to-end before you even started. You will do this together with your stakeholders/customers during a workshop that will include a lot of walking around, questions and writing on stickies.
What you need is:
- A large wall
- Stickies (Post-its)
- A few Stakeholders/Customers that will use your product/service
- A team working Scrum (Product Owner & Development Team) that will build the product/service
- A Session Owner (Scrum Master or Coach)
You start by creating a grid on the wall. The names of the columns are the categories that the product/service must think about. The names of the rows will contain the products you want to provide. For clarity, its easiest to only discuss a single product during a session, but you could add more if you want. Be sure to add enough space between rows so the wall won’t be too crowded.
It will look a bit like this:
Phase 1: Start session
The idea is to write down features and wishes from Stakeholders/Clients on stickies and place them under the correct category. The idea is that if you have Stakeholders or Customers that -for example – a certain kind of Database, a certain way of aggregating logs or a Multi-Factor Authentication – they’ll let you know!
Of course, the Scrum Team or Session Owner can help the Stakeholders along by asking questions. If you can get to a common understanding what is most important, you’re doing a good job. Once you have a bunch of features and wishes you can use this information to distill some information.
Sometimes a Stakeholder or Customer will come with a very large feature or wish. It’s important that the Scrum Team breaks this feature down to several user stories that can be achieved within a single sprint. If the Stakeholder or Customer can only come up with a vague product idea, you can call it an Epic and try to break it down into features. You can then break these down into user stories for the team to work on.
Epic: A block of work that requires several sprints to complete
Feature request: A complex functionality for the product or service that could be broken down into more detailed blocks of work. Could also be seen as a “Collection of User Stories”
User Story: A block of work that can be completed within a single sprint (normally 2 weeks). These blocks often use the phrase: “As a [Client] I want [Functionality] so I can [Do something]”
Phase 2: Stick’t on the wall
The stakeholder mentions why he’s here: Since the company want improves sales, the marketing department has decides to employ a broad range of digital media, such as an app, a website and internet advertising to reach businesses and customers across the world – with a tailored tailored marketing message for each type.
Alright, let’s make these our first epics:
EPIC 1: As the Stakeholder I want a professional website to reach out to businesses
EPIC 2: As the Stakeholder, I want an app to reach customers with a tailored tailored marketing message.
EPIC 3: As the Stakeholder, I want internet advertising to reach those hard-to-get people
(You might notice these look a lot like User Stories. That’s intentional – it’s basically a HUGE user story.)
Now it’s time to cut that down to feature requests. Let’s only deal with the Website Epic
- Feature Request: “The website should be up and available”
- Feature Request: “The website should contain blogs of noteworthy people in the industry ”
- Feature Request: “The website should allow people to log in to view a members-only area.”
- Feature Request: “The website should contain live-chat”
Break these feature requests down to user stories. You might very well discover that any item requires even more breaking down. That’s no problem but perhaps better suited for a Refinement session / Sprint Planning
- Feature Request: “The website should be up and available”
|Website||Use of MySQL Database
Automated Database deployment
|Sit with marketing department to get an idea of the design|| Admin panel should have multi-factor authentication
Last failed attempt login timestamp should be visible.
Website design should follow OWASP recommendations
|All actions by administrator should be logged||None||24/7 Monitoring for hacking attempts||Highly available by using AWS Infrastructure|
Do this for all features. If the Stakeholder already has a vague idea of what is most important to him, be sure to start with those Epics or Features so you have the most important items done when the time runs out – otherwise just start from the top.
Phase 3: Voting on Priorities
- From the entire list of items, ask the stakeholders to arrange the Epics from high priority to lowest priority.
- Grab all Feature Requests of this Epic and ask the Stakeholders to arrange the features from high priority to lowest priority.
- Of the top three feature requests, as the Stakeholders to vote on the most important User Story. You can do this by giving each stakeholder three to five ‘votes’ in the form of dots made by a marker or pen.
- Choose the top five user stories – these will get the highest priority in the Product Backlog going forward.
By now the Product Owner should have a reasonable idea which items the Stakeholders prefer. You could immediately add a Refinement Session together with the Stakeholder so you can break down the user stories into real detailed stories (“What, Why, How”). These items will go into your first sprint.
If you have time you could also refine items for the hypothetical second and third sprint. (Of course, since Scrum is based on empirical data, you don’t actually know if you have the capacity to pick those items up at that time – but make use the stakeholders while they’re there!)
Phase 4: Get busy
By now you have
- A Product Backlog with a few prioritized items.
- A happy Product Owner.
- A happy Stakeholder with the idea that he’s part of an A-team.
Get ready, because now you can start with the REAL work of building the product or service.