The hardest part of software development - identifying and prioritising business requirements
Writing software isn’t difficult when you know what you want to do. Coding is the easy bit. The tricky bit is working out what your end users and your customers really need. And when you think you’ve done that, you’ve got to document it and communicate it in a way that makes it as easy as possible for your development team to design and build the best solution.
There are some challenges that make the job harder:
- You might not be that close to the end user. It can be harder than you think to find out what people really want, particularly if you’re building software for a customer that sits between you and the end users.
- You have some bigger, more vocal customers who have different requirements and want different features.
- You’re a business where internal teams compete for limited development resources.
- Commercial pressures inside your business can mean unrealistic expectations. You’re under pressure from business development to deliver a lot of new features in too short a period of time.
- You’re being asked to add new features to a big, well established product. A lot of software products get more complicated over time and it becomes harder and harder to add new features.
What are the solutions?
Remember this goal - a single product backlog of high quality requirements.
You want as much clarity as possible before you put user stories/requirements into the product backlog. That means doing some high quality upfront analysis work around bigger items and it means filtering out as many bad ideas as you can.
Here are some things you can do to streamline they way you identify, prioritise and document user requirements:
1. Simply the admin.
Do everything you can to avoid lists of requirements in MS Excel - they are always hard to read and you inevitably get versioning problems. Software systems like JIRA are purpose built for managing and sharing product backlogs.
2. Create a template for documenting requirement.
Put requirements in simple tables and avoid long wordy specifications. Use your document template for the requirements analysis work you need to do around larger items before you can add them to the product backlog.
Document requirements as ‘user stories’ - short statements that describe the requirement from a user’s point of view. A larger requirement can be broken down into a collection of user stories. You can also add in simple mock-ups and screenshots where more explanation is needed.
Here’s an example of a requirement presented as a user story:
“As a trainer I want the course booking system to include delegate attendance tracking so I can quickly record who attended each of my course sessions.”
3. Make your end-to-end requirements capture/user story discovery process transparent.
Encourage your colleagues to see it as a kind of production line. You start at one end with vague ideas (some good, some bad) and finish at the other end with developers working on new features.
Make sure your colleagues understand that new feature ideas need to go through a simple process of analysis and validation before they can be added to the product backlog.
4. Use customer focus groups.
Talk to customers - find out if they are really prepared to pay for new features. Use very simple mockups/prototypes to test out larger ideas before you commit valuable developer time.
Can bigger developments be simplified and turned into mini ‘minimum viable products’? Maybe you can slightly simpler versions of new features, get some user feedback and then do further enhancements.
5. Find other ways to test big ideas and features before you commit to development.
Amazon famously tests out new product ideas with mock press releases. Before building and releasing a new product Amazon will create a mock product review - they call it a ‘working backwards document’. They then test out the mock press releases on internal staff. Products only get developed if people like the press release.
6. Educate your colleagues about feature development time.
Estimate development jobs and then compare estimates with actuals. Do this for every development sprint.
Share the data about your development team ‘run rate’ with colleagues - a lot of people involved in the wider software/product development process have no idea how long anything takes to build and test. You want your colleagues to have a feel for the relative cost of development of different features.
7. Appoint a Product Manager.
You need someone who can sit between your development team and the people who request new features (internal and external customers).
The Product Manager role is super important - it’s got to be someone who understands the vision for the product and can own/manage the product backlog. They need to understand your customers and what they want, but they also need to understand software development and how long it takes developers to build and test new features.
Conclusion
Maybe the 80-20 rule as it applies to software development - 80% of the value in your software comes from 20% of your requirements. Or at least it will if you don’t get the requirements right. The good news is there are simple things you can do to filter out bad ideas and improve the quality of what’s left.