The Product Novella - an Agile Planning Tool to make better products
“The Product team has no idea what they are doing”
“We write all of our stories during the day and code at night”
“This feature sucks and we are losing to our competition”
Does any of the above sound familiar? I heard these whispers in 2001, 2008, and 2020 and all the years in between. How do we hire smart people, improve our processes using agile and lean development approaches, yet still wind up in the same situation?
14 percent of software projects fail. Of the projects that didn't fail outright, 31 percent didn't meet their goals, 43 percent exceeded their initial budgets, and 49 percent were late.* Also, up to 75% of business executives feel that their project is doomed from the start. **
One of the biggest reasons I have seen Agile projects fail is due to a lack of planning. As fun and as lightweight Agile development can be, there is a fear that doing any upfront planning makes you antiquated and "not Agile." If you are building software for enterprise customers, you must take the necessary steps to ensure that the product features you are making are needed, and will not cause pain to them when launched. Just cranking out features without a holistic plan
My dad was a plumber. Can you imagine showing up to a slab on concrete on the same day as the carpenters, electricians, and __ and making it up as you go along? There needs to be some plan besides "3 rooms, 2 bathrooms, and a kitchen". Otherwise the individuals will just build their interpretation of the instructions, and not create a whole product.
A big reason why I have seen issues in agile product rollouts is with the vagueness around product management. There is a TON of material on agile project management. There is nowhere near enough guidance on getting the Roadmap that execs and sales teams use to getting to be artifacts that can allow for planning and avoid the technical debt that gets added in when features are pulled from a backlog and put into sprints.
I do think that themes, initiatives, epics, and stories are a good step in the right direction. I still have yet to see this framework used consistently. What mostly happens is that this happens for a big kickoff, and then the familiar cadence of a sprint, stories is rinsed and repeated. I am not suggesting that everyone goes back to writing 100-page manifestoes with Rational Rose diagrams. I am proposing that we add a step in the process where we write 1-3 pages about what we are trying to do with each initiative. Writing makes you concise; it makes you think. Like Jeff Bezos' famous management strategy, when you put your thoughts down in a structured format, you focus on the essential things.
Instead of walking into a grooming session with a list of stories based on themes, try the suggestions below.
Create a roadmap (if not already created)
There are hundreds of stories written about Agile Product Roadmaps. Here is a good one.
Write your Project Novella
I am calling this artifact a “novella” instead of a Project Brief, because there is more detail needed than a Brief . Now is the time to connect the high-level roadmap Themes to the Initiatives.
To be clear, "Better Insights" is a Theme. From there, "Reporting" is an Initiative. An initiative can take a quarter or two to deliver. Your job is to write about the Initiative, and list all of your hopes and dreams. You have normalized customer feedback and created a definition of what is needed as a whole. Some tips about writing this:
Feel empathy. Remember that there will be UX, devs, QA that will be reading this and wondering how it will apply to them.
When the UX, devs, and QA ask questions and ask you to create a 2nd version, it does not hurt the initiative. Clarity helps planning.
Adding in lightweight UX (Balsamiq, Canva, ppt) can help, but it should not be a limiting factor.
Do competitive research. The worst thing you can do is release something that is just "ok" and is only slightly better than other products. Leapfrog the competition, because they will surely be making their product better while trying to keep up with their current version.
Meet with your development lead
One of the most productive things that you can do is to set up a meeting with the architect or dev lead. Just meeting alone should lead to a much better outcome. Grab some coffee (virtually) and have a normal conversation. Let them review the document a few days in advance, and be prepared to engage in a lively discussion. They might challenge you on some of the ideas that you propose, and that is a GOOD thing. They will also give you a list of homework items to do and things to research. They will suggest when UX is needed. They will think about databases, hosting, scalability, tools required, and many other things that are not considered when we create stories for features.
The majority of conversations that I had with the developers in these meetings had them thanking me for involving them and then saying, "before I can estimate this feature for you, can you answer these questions?"
How does this affect customers already live?
How does this affect our scalability? Are we going to create a feature that will drive a traffic level that our hosting instance cannot support? Will our database be able to handle the number of queries being thrown at it?
Have you talked to the CEO?
From there, you will have a some homework that will lead to a new draft that the dev team will sign off on, and the whole team will feel shared ownership.
Write your detailed stories in advance
One sure-fire way to have a development team "talk instead of code" is for your stories to only follow the standard "_ as a _ want to _ so I can _" format. I agree that the standard framework is a beneficial tool. You should follow those frameworks up with more detail.
Here are some tips:
Add UX if there is a visual component.
Account for failure scenarios. What happens when the request hangs? What happens if two people click on the same thing at the same time, and that is the last product available? QA will be able to write better test cases if you provide this detailed information upfront.
Think of the administrator as a user
Don't be afraid to ask your customers for their feedback if they were the ones with the suggestions. They will not "own your roadmap," and they will feel more like a partner.
This looks hard!
Doing this upfront work appears to be a lot of work. Agile experts argue that doing too much detailed work in requirements is wrong. I agree with them when it comes to creating simple tests, MVP's, and failing fast. Once you have customers, and especially enterprise customers, more detail is essential. The time you spend fixing and retooling features that are slapped together will be much longer, and more painful to your paying users.
Key Takeaways
Make sure you have a product roadmap /strategy document
Write your product novella
Meet with your dev lead
Write your stories
Build great product! (and talk to your customers!)
If you need any help or guidance with any of the above, schedule some time to chat. I would love to help or hear your feedback.
**https://www.geneca.com/why-up-to-75-of-software-projects-will-fail/