Break things down

In software engineering, it's not technical prowess that most often prevents projects from being completed on time and within budget. It's lack of clarity.

If features and tasks aren't understood by all stakeholders, both in their content (the what) and purpose (the why), there's a risk those invalid assumptions become real code.

One habit I've developed in the course of my career is breaking things down. I'm not afraid to dissect and extract everything from a set of requirements until I'm confident I can execute their implementation with precision.

In practice, that means taking an epic feature specification, i.e. "As a payroll administrator I want to be able to view a payroll summary report" into all of its smallest divisible parts as separate tickets in your project management software:

• I want to see a list of my employees
• I want to see all of my employees take-home pay
• I want to see my total payroll tax for the pay period
• Et cetera

Managing multiple tickets for one feature might create a bit more project management work, but it enables team members to discuss each component of the feature separately and in-context.

Imagine if you hadn't broken down the original user story, and imagine you wrote the all of its requirements in a single ticket. If there's a question about more than one of the requirements (which, there will be), you're now forced to engage in a disjointed discussion thread about all of the questions all in one place. This is confusing and difficult to parse in the long-term.

By creating multiple tickets, you're able to have more contextual discussions about razor-thin specific topics. I can discuss what exactly it means to see "a list of my employees", and it won't be ambiguous which requirement I'm referencing because the discussion is contained within its own ticket.

This also enables you to track the progress toward completion more granularly. Instead of the "doneness" of the epic feature being represented as a binary state ("done" or "not done"), it can be represented fractionally (four out of nine tasks completed). This is powerful in representing progress to stakeholders because it ensures them you're making progress, even if some aspects of the feature are more effort-intensive than others.

The next time you're writing functional requirements, ask yourself whether there's a way you can break it down further. Your team will be more equipped to ask questions and you'll be more equipped to track progress.