When we have a new theme coming up, we usually start a few weeks or months in advance by having one or more brainstorming meetings with our Product Owner and possibly other stakeholders. The PO often draws examples on the whiteboard as we discuss: algorithms for calculations, or diagrams for workflow. We ask questions to understand the purpose of the theme, the business problems it will solve, who will use it and how. We talk through various technical implementation designs. These meetings are usually timeboxed to one hour. Having a few days between meetings gives us time to think about what we’ve learned so far and possibly do research.
Once we understand the theme, we work with the PO to break it up into user stories, prioritizing them according to dependencies and risk, and estimating them. Sometimes we just estimate the theme so the business can think more about whether they want to prioritize it. When we actually start work on the theme, we usually feel pretty well-prepared. Still, when we get into actual development, we sometimes find we missed some important aspect of the feature. Sometimes after the theme has been released to production we realized there was a ripple effect we hadn’t thought of.
Since participating in a workshop where Jeff Patton introduced his story mapping technique, I’ve been lobbying to try story mapping when we start work on a new theme. Our product owner, Steve, got his wires crossed and mixed up “story mapping” and “mind mapping”, and decided to mind map a new theme on our big rolling whiteboard. We’d had a couple of brainstorming meetings on this theme, and had written and estimated stories for it. He thought it would be a good idea to mind map everything we could think of about this theme, and take a fresh look at it.
I still want to try story mapping, but this mind map worked really well to help us review the theme. Steve’s color coding was helpful. Our current system has a one-to-one relationship between a “plan sponsor” and a 401(k) plan. In truth there could be multiple sponsors for each plan, so we have to break that one-to-one relationship, which is the green branch of the mind map. Those are the first stories we’ll do. Then we need to provide a way for one plan sponsor to have an ‘administrator’ role and be able to create accounts for other sponsors in the same plan. The management UI for this is the orange-colored branch. One sponsor will be the “Authorized Representative” (“AR”) and that is the name that will go on official documents. That’s reflected in the purple branch, along with reports, queries and email communication. The brown-colored branch is future functionality, which we want to keep in mind as we deliver the initial stories. In drawing the mind map together, we thought of areas we hadn’t considered in previous meetings, such as recording which users make which changes, and how td to do or know? What book is missing that would send newbie testers in the right direction?
