How do you turn regulatory requirements into user stories?
You’ve just received the regulatory document for your product in the form of a 126 page document…where do you start?
This is you, you’re a business analyst, product owner, process analyst, product manager, business consultant, etc. and your brain is trying to process the massive requirements document you just got from a business partner and you mutter to yourself… “oh crap, where do I even begin?!”
We’ve all been there, the daunting task of breaking down this work for your development teams to turn it into a reality. The pressure is on, you need to get work ready for them. Now what?
The first thing you need to accept, not all projects are rainbows and butterflies. You may have been lied to in your past product management role by being told things like, “you’ll build new features requested by users!” and “UX design and measuring feedback loops are a big part of how we decide what to build!” Well this maybe true for a lot of your projects, but when it comes to certain requirements, such as things that need to meet laws and regulations set by the government or other fancy departments with three letter names, you don’t get these luxuries. Your product needs to do as the law states, there’s no feedback loops here.
Sorry to burst your bubble, but you don’t always get to make shiny new features and crazy innovative designs. Sometimes your product just needs to follow the rules, and that’s life!
Still with me? Good! Let’s get to the tips and tricks part…
OK so you know making the regulatory changes are a reality, no way around it, you’ve accepted it at this point. Now what do you do? Here’s how I start:
Just try something!
Stories/tasks don’t document themselves. I use my early JIRA (or your software of choice) items as just brain-dumps for me. They aren’t super organized, and not even close to polished stories I would give to my teams, but they are in a form I can digest.
If I see something in the regulations that sound like a change I need to make to my system, it goes in a story, but with way less words. For example, if the regulations say “the plan shall have a right to appeal the denial before the Department and in the district court as provided by 458 CMR 2.14(5) and M.G.L. c. 175M, § 8(d).” my story might say “update appeal processing” and that gives me a place to start putting some acceptance for what needs to get updated. It’s out of the document, and into my system, it’s not pretty, but it’s there!
The polishing comes later with your team. Once you have enough digestible information, the team can start asking questions and you can make the story nice and neat.
Remember, what does a user story mean?
A user story is the smallest piece of work that represents some value to an end user and can be delivered during a sprint. Important things to note here, small and valuable.
Simplicity — the art of maximizing the amount of work not done — is essential — Agile Principal #10
For regular feature work your brain might not always think like this. You might be thinking about some sort of functionality to deliver that really changes the way something works. In the laws and regulations world it might be different. The change might be as small as changing some words on your EULA form. Or it could be changing something to read 1 week to 7 days. It could be a minuscule change that your brain would normally wrap up into another feature story. My advice? Make it it’s own story. You do not want to miss these small details when it comes to laws and regulations.
So if you are processing the document and see something like this, make a story! No one is charging you (I think) for the number of stories you are making in JIRA.
Stick to the format, remember the why
It’s easy to write these stories in a kind of lazy format. Example:
As a user, I want to only enter 7 days in the time picker so that 7 days is saved to the database
This example doesn’t clearly state why they need to pick the 7 days, just states that it needs to be saved to the database. Why does it need to be saved to the database? Why is it even available to the user to see? Can this be automated somehow? These are all questions the dev team (and you!) should be asking if looking at this acceptance. Sometimes keeping the story too simple doesn’t really inspire any creativity. Here’s a better way you could write this story to give some inspiration to an otherwise drab story:
As an insurance carrier, I want to display 7 days in a disabled input to the user, so that they cannot change the state law for the program
Takeaways
- Project work isn’t always beautiful, don’t stress, just get the work done
- Start somewhere, brainstorm and brain-dump into your story tracking system and clean it up later
- Be simple
- Remember the why, don’t be lazy!
Hope you found this helpful! If you enjoyed the article, you can clap up to 50 times 👏 Comment or message me with other topics you would like to see covered. Thanks!
Opinions expressed are solely my own and do not express the views or opinions of my employer.
Connect with me! https://www.linkedin.com/in/ericandrews0531/ Add me on LinkedIn and let me know what other topics I should cover!
