Because I feel responsible for bringing Scrum to my current company, when someone asks me a question about how to do something, I feel compelled to tell them. After all, I am the expert. Without even realizing it I was giving the answer before letting someone think about how they would answer the question.
After my Scrum Master Certification I became determined to change my ways. It wasn’t long until a team member asked me for some help trying to get a large amount of work to fit in one 2-week sprint. He was working on changing some complex screens for the sake of usability. The ideas were sketched out in mock-up artifacts, and he was wondering how such a massive amount of work could fit inside our two-week iterations. He had one developer look it over and guess that it would take more than three weeks to develop and was despondent, thinking it had to all go together and be delivered in one iteration.
After he explained the situation, showing me page after page of printed out wire frames, I asked him if there was anything stood out that could be delivered whole without dependencies on another part of the change being there. He pointed out one thing he thought was the coolest bit of work and the most usable must-have, but then realized there were other things that had to be in place first. He worked his way back to a layout that had to be in first, before anything else. I asked him what the value was to the customer to only have that little bit, and wrote it down as he told me. From the context of the screens I knew the user, and asked him what was really being accomplished and wrote that down. We had our first user story, in the traditional user story phrase of as a <user role> I need to <perform an action> to be able to <add value>.
We then worked on what was dependent on that and so on, until he felt there was some real value added to the application, and grouped those as a theme worthy of releasing live. We worked on to the next bit of functionality and so on, until we had about a dozen stories broken in to a few releasable themes. After we finished that, it was time to figure out how long it would take to get the all done.
I asked how big he thought each story was. He started by stating the first one was rather large, and I asked if it was really large, or medium. He stated it sounded like clothing sizes and I asked if it was OK to use t-shirt sizes to see how big each story was that we’d written down. After we finished that, we looked at the worst-case scenario for getting it done, using rules like a small and medium could be done in a sprint, but an extra-large would have to go by itself. We then did it again with best-case, and figuring the developers would learn along the way, and that maybe a large and extra large near the bottom could be finished in the sprint. Based on this we had what felt like a pretty accurate estimation of needing 3 to 5 sprints, maybe 6, depending on what other work was at high priority, to finish off all the work.
He thanked me then and there for my help, wondering how he could have done it without me. In essence, he really had done all the work and the only real work I did was writing down the stories as he told them to me. I asked if there was anything else I could do, such as write the stories up and discuss with the Product Owner, but he was clearly happy to do this work himself. He no longer felt overwhelmed of what had to go first, how long it would take, and what to do next. By prompting him and taking a true interest in all his effort, he was able to come up with the answer himself. I feel it was my first facilitation success.
One Response to My First Facilitation Success