Software requirements are a key enabler to high-performing teams, and itโs fair to say Iโve never encountered an underperforming development team that didnโt also have a requirements problem. However, software requirements are only as good as the process they are used in, and you would be forgiven for believing that more detailed requirements fix everything. The situation is more complicated than that.
Defining the right requirements, at the right time, to the right level of detail, for the development team you have, is the skill of software requirements. Itโs like getting the timing right when dancing the tango. You need to know when to define epics at a roadmap level, when to write user stories, when to refine them with the technical team, what detail to include, and what to leave unsaid.
Here are a few tried and tested suggestions to get you started, applicable across various types of agile:
- User stories should focus on what the software needs to do, rather than how it should be done (leave that up to the developers to decide).
- Acceptance criteria usually make up 80% of a storyโs content.
- A developer and tester should review each user story, and only once both are satisfied, should the story be considered ready for development.
- Decide if stories must be refined outside of the current sprint, or if they can be picked up and refined at any point.
- Avoid writing stories too far in advance and deliberately keep the backlog small.
A well-functioning agile process is the foundation for better software requirements and high-performing teams, and this requires tailoring your agile framework to the organisational context in which your team works.
Established environments should be familiar with agile software development, and tailoring will be focused on fine-tuning rather than wholesale coaching and education. Expect to spend your time addressing items coming out of retrospectives. Emerging environments, on the other hand, may require significant education and coaching before agile working is even possible. However, efforts to educate stakeholders and embed agile working are well spent, even enjoyable, in the company of receptive colleagues.
If your developers are struggling, perhaps they need better guidance?
Our Software Requirements can help with that.