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 solution is usually 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’s 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 makes 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.
Putting this into practice involves rolling up your sleeves and really considering the specifics of your team’s software development process and the organisational context and culture they are working in. Inevitably, you’ll need to tailor your choice of agile framework, as a well-functioning agile process is the foundation for better software requirements and high-performing teams.
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. Unfortunately, there are some environments where agile working is simply not possible, and attempts to do so fail, sometimes spectacularly. The reasons are varied, but it’s best to avoid those situations in the first place.
I take back my infamous post, Removing Agile from my CV, written in 2019 as a direct response to several thoroughly unsatisfactory experiences as a full-time Scrum Master and a burgeoning agile certification industry. I’m interested in agile software development, now more than ever before, particularly framework tailoring, and I plan to add ‘agile’ to my CV once again, but this time as a software requirements analyst rather than a Scrum Master.