← Scrum Master Toolbox Podcast: Agile storytelling from the trenches
Scrum Master Toolbox Podcast: Agile storytelling from the trenches
From Requirements Chaos to Story Mapping Success—How Planning Transforms Agile Teams | Carmela Then
00:16:16
Loading summary
Transcript19 lines
- [00:04]
A
Hey there agile adventurer, just a quick question. What if for the price of a fancy coffee or half a pizza, you could unlock over 700 hours of the best agile content on the planet? That's audio, video, E courses, books, presentations, all that you can think of. But you can also join live calls with world class practitioners and hang out in a flame war free and AI slop clean slack with the sharpest minds in the game. Oh, and yes, you get direct access to me, Vasko, your Scrum Master Toolbox podcast. No, this is not a drill. It's this Scrum Master Toolbox membership and it's your unfair advantage in the agile world. So if you want to know more, go check out scrummastertoolbox.org membership. That's scrummastertoolbox.org Membership. And check out all the goodies we have for you. Do it now. But if you're not doing it now, let's listen to the podcast. Hello everybody. Welcome to our Wednesday the coaching challenge day here on the podcast this week. Joining us is Carmela. Then. Hey Carmela, welcome back.
- [01:23]
B
Hello Vasco. Thank you. Glad to be here.
- [01:26]
A
Absolutely. So Wednesday is coaching day here on the podcast so that we can have a coaching conversation with hoping to model what coaching conversations feel and sound like for our audience. The goal is not for me or for Carmela to coach each other, but rather for us to explore a topic together with curiosity and of course trying to come up with experiments that we can then put in practice and move forward. So Carmela, what is the topic you're bringing to us today?
- [01:58]
B
I'd like to actually talk about planning and yeah, so planning, I am not only just referring to Sprint planning, I am actually referring to a bigger long term or more about a feature style of planning. So a little bit of a background. So it all started with. So I joined this company and this company has an interesting way of jumping into things and starting to write requirements and without actually thinking what they are trying to achieve. So there are a couple of things. They have their vendors and they also have of course they are the in house technology landscape. So things that they want to build with the vendor and the in house, it has to be integrated into the in house technology landscape, the platform, all the platforms. So even with the requirements gathering they, they were thinking that once we've done these vendor requirements and I could just checked it, check it over the fence and the in house technology team would know exactly what they need to do and without anybody who was leading them into planning the feature planning how to Deliver the feature, breaking down like look at the entire story roadmap and breaking down the story. So the team has been running on that kind of model for a number of releases. So almost a year. And the result, as you could guess Vasco, it was horrendous and the business promised a number of things but because we didn't have that kind of roadmap, the kind of full story breakdown and people the team was writing story on the fly while they are building as well. So that has created a lot of rework, a lot of confusion. And as the result of it, majority of the team members were overworked, stressed and still feeling like a little bit of a failure because not delivering enough business value. And the product owner kept on having to go back to the stakeholders and say we didn't do this because of this, this, this, this, this. That was a really hard conversation for her and just because I wasn't in any Scrum master kind of position. And that's probably why she didn't come and ask me in the. In the beginning and I was too occupied with everything else. And one day she just reached out and she said we can't continue to do this. Something has to change.
- [05:34]
A
That is a great realization right there.
- [05:37]
B
Yeah. And luckily we have formed a really great relationship before that. And I kept on telling her that we need to plan this better, we need to plan this better. And she's like we need to change and give me some idea like how. How would you approach this? And so I started to with her the experience to culture in a way and how I used to run workshops before the kickoff of any feature. So it has to start with gathering the business stakeholder, the SME together and get them to talk through. Walk us through the end to end business like a business process. How and how they anticipate the new business process will work.
- [06:32]
A
How were they prev. How were they creating the list of requirements before if not talking to the subject matter experts?
- [06:42]
B
So they. They were. That's a great question. I don't know how they spawn the. The in house team, how they created like this stories. So maybe because we have. If I take a step back prior to that vendor has developed something that can. That has to be integrated into the system. So the idea is to integrate into it. So there are a number of key people have some ideas on how the integration should work. So it is really based on that. So it's almost like technology, like what you say, the technology lead driven rather than business process driven. So technology leader amazing themselves but then they just because they don't understand how the user will be using the system and how the process should work, they can only guide the team up to the certain point.
- [07:46]
A
Yeah. And only about the technical aspects, of course. So what did the product owner say when you suggested that maybe we should do a kickoff gather the subject matter experts.
- [07:57]
B
This time she, she was very happy to embrace the idea. So I told her that we have to get, we have to go through a series of workshop to bring our stakeholders onto the journey to gather their understanding. Ask them do they actually need on the internal system before we could integrate into the external system. Once we integrated into the external system, what's their expectation from it? Like what they want back into their day to day BAU sort of environment. So we did a series of workshop around that gather their requirement, walk away understanding it a little bit more and did a little bit the a playback session. So we basically. So I took your requirement, I understand what you're trying to say. And this techno, we discuss it with the team. This is how we think we can achieve it.
- [09:01]
A
Kind of a validation of a feedback point.
- [09:04]
B
Yes, that's right. And is that, does it fit what your. Does it fit your expectations? And so throughout these we introduce the story map again. Previously there wasn't part of like end to end kind of story mapping. So we introduce the story map, we tell a story from the beginning, this is what you do and the little checkpoint, this is what you do and this is the end result, this is the end. So we string that together and under each big step we have small steps under one story card. We break it down into smaller story cards of smaller story points and stories. So that's how, that's the math. That's a visual app that we use consistently in all of the workshops. So first we did that with the business, we did the playback, the stakeholders happy with it and then we use the same story map, bring the team again and say okay, we have done first round of requirement, the business is happy about it. Now with this story card, what do we need to do to achieve it? So we coming down to technical details.
- [10:28]
A
And how did that planning go with that approach, that timeline, how did it go.
- [10:36]
B
With the planning? So now we have majority of stories broken down. So the detail like the one that we know in a little bit more details that becomes something that we could start building while we have some hairy ones that we don't really know and we accept that and well some of the team could focus on building the cars that we have Some ideas and then the other one, we take some of the time, we allocate some of our time in every sprint to actually look at solving the bigger one and to break that down further. So in the future sprint we could build it.
- [11:21]
A
Absolutely. What I really like about this approach is the interactivity. One of the things I very often say is that if you could boil down agile to just one thing, that one thing would be reduce the feedback loop length, whatever that is. If it's two days, do it in one day. If it's a week, do it in two days, whatever. Like always make it shorter. And you were doing that when you were involving the business people early on, you were doing even the playback, which is yet another feedback loop that shortens that ability to collect feedback so makes it more feedback right on time. So when it's the most appropriate, right, like not, not weeks later or months later, and, and then involving the team and, and figuring out what, what's most understood, how do we get it done now? And then the bigger ones, the hairy ones, as you call them, we'll do them later, but because we still need to investigate that further, figure it out, whether it's from technical or, or business perspective, to continue to refine that. And I think that's a great approach because it really takes advantage of this core power of agile, which is the short feedback loops.
- [12:31]
B
Yeah, absolutely. And that story map also helped us prioritize it. So now the entire team, including our product owner, could look at how many stories on the board and the team has done a very quick, high level kind of estimation in terms of the effort that they that's required to build it. And knowing how many sprints do we have to build to bring this to life, which is our promise to the stakeholder that we will go live with it. So armed with that, then the product owner could go, all right, we have these items that are higher priority, but then just because they are very complicated, I better not, I better reduce the effort, like, you know, the building capacity of the team so that we have more time that we could invest in investigating this big hairy one. Because, for example, they are really important. We have to get this out. So that also becomes a really a good prioritization discussion tool.
- [13:51]
A
Thank you for sharing that story with us, Carmela.
- [13:54]
B
You're absolutely welcome.
- [14:00]
A
All right, I hope you like this episode. But before you hit next episode, here's the deal. This podcast is powered by people like you, the members who wanted more than just a inspiration. They wanted real tools and real connection to people who are practicing Agile. Every day we're talking access to over 700 hours of agile Gold, CTO level strategy talks, Summit keynotes, live workshops, E courses, Deep Dive interviews, books, and if you're into no Estimates, we got the pioneers of no Estimates in those Deep Dive interviews as well. Agile Business Intelligence, creating product visions, coaching your product owner courses, you name it. You'll get invites to monthly live Q&As with agile pioneers and practitioners, plus a private Slack community which is free of all of that AI slop you see everywhere. And and of course, without the flame wars. It's a community of practitioners that want to learn and thrive together. It's the best place to connect with community and learn together. So if this podcast has helped you before, imagine what you will get from this podcast membership. So head on over to scrummaster toolbox.org membership and join the community that's shaping the future of Agile. We have so much for you, so check out all the details@scrubmastertoolbox.org membership because listening is great. It's important. But doing it together, that's next level. I'll see you in the community. Slack we really hope you liked our show. And if you did, why not rate this podcast on Stitcher or itunes. Share this podcast and let other Scrum masters know about this valuable resource for their work. Remember that sharing is caring.