I’m about a week or two behind on writing anything, but I’ve
been out of town for the last two weekends for a bachelor party and wedding of
a good friend of mine, and I just haven’t made time. Anyway, I wanted to write
a follow up piece on my earlier post of How Not to Do User Story Mapping. I mentioned in that post that I was planning
a workshop on User Story Mapping and Adaptive Planning, and I wanted to write a
follow up on how my workshop went.
WARNING: This post turned out kind of long! Sorry I’m long
winded…
This was the first workshop I’ve conducted since leaving
recruiting and transitioning into an Agile Project Manager role, so I’m by no
means an expert, but I’ll at least share my experience.
Before I get started, I want to summarize why I believe User
Story Mapping is so beneficial, just in case you are unfamiliar with the
concept or haven’t done them yourself. As I’ve mentioned in prior posts, I
support two highly technical backend shared services teams, and the stories we
were writing were very detailed and complex and it was nearly impossible to see
how they tied into the big picture of what we were building. In fact, I found
that we often were building something without truly understanding the big
picture or how it tied into the problems we were trying to solve for our customers.
Then the APM team decided to read User Story Mapping by Jeff Patton for our Q2 book
read and it couldn’t have come at a better time!
The idea behind user story mapping is that you bring ALL
project stakeholders together to talk about the Who, What, Why of a project and
build out a map of what software needs to be built to solve a customer problem.
It helps everyone to gain a shared understanding of what is being built, and
with larger projects that are split among many different teams (which tends to
happen at CareerBuilder), it gets us all on the same page with the complexity
of the project and everyone better understands who is building what (i.e.
better visibility into dependencies).
For my workshop, I used three resources to help me prepare:
- User Story Mapping by Jeff Patton (I highly recommend this book)
- Chapter 5 on Adaptive Planning from the PMI-ACP exam prep book
- YouTube video by Ahmed Sidky on Agile Estimation (I also referenced his paper here).
I’m very fortunate in that I had full support from my Dev
Manager, Product Owner, and Engineering Lead, as well as buy-in from the team
to take a full afternoon to run this workshop. That’s four hours of sitting in
a room and listening to me talk! Just kidding… we had plenty of activities
mixed in, but I still appreciate them actively participating when I’m sure they
would rather have been at their desk coding.
I structured the workshop to follow the sequence of events
of planning out a new project: Build a User Story Map, High Level Affinity
Estimation, break the map into potential releases, low level planning poker
(using relative vs absolute sizing, and complexity [size] vs time), release and
sprint planning, and finally daily stand up.
For the workshop, my Product Owner came up with a fictional
app that would control a robot to do lots of activities around the home (think
the Jetsons) such as cooking, cleaning, laundry, etc. Because we are a backend
team, they didn’t want to do an e-commerce style site and wanted something that
would involve a little more infrastructure setup. I also wanted it to be
different enough from their day to day work so that they wouldn’t immediately
try to translate everything back to their work, and instead would focus on
learning what User Story Mapping is all about.
Unfortunately, I think I still struggled to help them
understand the story flow that comes from building out the Backbone and Walking
Skeleton. I ended up abandoning that and moving towards building a story map that
would show how you get ready for work in the morning. Even though not all Story
Maps have to flow left to right chronologically, you generally want to map out
how a user would use your software in a left to right format, and getting ready
in the morning helped to show that. The getting ready in the morning example
also helped the discussion on breaking the map into releases as things like exercising
in the morning may not be MVP. It helped to demonstrate how we might move
stories up or down in the releases depending upon how important they are (note:
that also depends on your customer though; exercising may be a mandatory story
for MVP for some people, whereas for others it can go farther down. The key
point being you need to understand your customer for planning out MVP and
future releases).
For all of the estimation parts of the workshop, I pretty
much copied everything Ahmed did in his YouTube video. This was probably the
part of the workshop that resonated most with the team, so I’m glad I did. Practicing
planning poker with the fictional “unpacking a Uhaul” example really helped us
to surface a few things that we could learn about estimating together. For
starters, during the workshop we made several assumptions and it was only after
discussing why our estimates were so far apart that we realized we hadn’t asked
the right question yet. It was cool to see the light bulb go off when the
answer to that question helped us to then better estimate.
A lot of people complain about estimates and say that all of
the time we spend estimating is wasteful, and that we could actually be building
the software instead. I argue that they are missing the point of estimation; yes,
the business needs estimates (which the developers personally could not care
less about), but it is also a key tool to help the team ensure we truly have a
shared understanding of what we are building. An initial estimate that varies
is actually a great thing because it forces a conversation and develops shared
understanding; if everyone throws out the same number that can actually be
scary, because then you wonder if we all truly have the same understanding of
the complexity in mind.
Overall the workshop went very well and the team learned a
lot about User Story Mapping and Adaptive Planning. I gathered feedback from the
workshop and the biggest takeaway was they would have liked an example that was
closer to the work they do because we still had a big hang up on where
Infrastructure fell into the User Story Mapping. I think they’ve been a little
burned in the past because the business doesn’t understand the setup needed to
actually start building end user functionality. I think that’s partially
because we’ve never come together as a group (front end, back end, product,
business, etc.) to discuss a project like this. I don’t want to say we haven’t
had the buy-in of key stakeholders, because I don’t think we’ve asked stakeholders
(or even other teams) to attend a session like this, but we definitely have not
mapped out projects together like this in the past. If we bring all of the
teams together and build a map together, we can still create a backbone and
walking skeleton that is user functionality focused, and then use different
color post-its to help everyone see the different layers of functionality that
have to be built before that user benefit occurs. The business may not like all
of the infrastructure that has to be set up initially, but at least they’ll have
a better understanding of what we are doing and why we are doing it.
Only time will tell if we can get the buy-in across groups to
do User Story Mapping sessions together. At a minimum, this team at least now
understands how we can map out our next project so that we better understand
the big picture, and how we can also provide better visibility into the full
scope of the project. One thing I can already tell a noticeable difference in
is our estimation sessions. I think this workshop helped them think
differently, but it also helped me to better grasp some key concepts and
metaphors to use to ensure we keep our estimates as relative complexity based versus
absolute time based.
Do you do User Story Mapping sessions for projects? How did
you get buy-in from all stakeholders?
No comments:
Post a Comment