Whenever a client wants us to start a new venture with them, to initiate a project together, we work on defining business requirements (apart from making sure there is a business case in the first place). Traditionally, Business requirements form the “what” of the project. They provide an explanation on what should be built to achieve the expected return on investment. It is uncommon to find a detailed, technical description there. From a technical perspective, finding a flowchart or field definitions in a BRD (Business Requirements Document) is rare. As the document is owned by the client and often prepared by her, as professionals on the supplier’s side, we often expect from our customers not to cross the thin line between the “what” and the “how”. Figuring out the “how” is the supplier’s job. It’s the space where he can analyze the work at hand, translate the more general, business perspective into functions, data structures and flows, paired with interfaces required to interact with the future solution. Among others. This is how functional requirements are born. They form a pair – business “reqs” and functional “reqs,” they should directly relate to one another, where business requirements are the “what” and the functional requirements – the “how.” In a way, the BRD is part of a mandate to start a project, whereas the FRD (Functional Requirements Document) – a contract describing how the project result is to be built.

Here’s the challenge. Agile is founded on the premise that suppliers and customers are able to work out requirements collaboratively in the form of user stories, maintained in a backlog of remaining work, detailed iteratively as needed – based on priority / proximity, aligning in tight iterations and frequent feedback. In theory this is faster as there is no dichotomy . In practice… I have yet to see this work well.

Granted, agile requires sufficient organizational maturity with the new artifacts, events, and roles – Product Owners able to own the backlog, empowered and knowledgeable enough to detail requirements and decide on priorities.

But I haven’t seen many Product Owners like that. Plus, with increasing complexity of the business landscape and progressing specialization, they simply cannot be know-it-alls, right? Even having sufficient business acumen, they won’t be able to drill down to technical levels detailed enough to provide a sound basis for development work.

How do we deal with this? From my perspective this is Agile’s uncharted land, that’s where “there be dragons.” Pre-sprints, parallel analytical sprints are just means to patch this up. The issue possibly requires several “whys” before we reach the root cause. My bet is that complete functional requirements are a necessity that cannot be neglected, and that they should form a response to whatever the business requests. Having agreed functional requirements we can expect viable “work packages” which can be decomposed, estimated, and developed with a higher degree of accuracy.

“The schedule model simulates distinct scenarios and situations that predict milestones and completion dates according to the project’s actual and future data input by the project team. It is an important tool used for communication and managing stakeholder expectations.”

From Practice Standard For Scheduling, third edition, PMI

What do you find better? An ordered stack (a backlog) or a sequence of actives of varied length (a schedule)? Agile advocates the former, with waterfall we got used to the latter.

It’s easier to move items up and down in a stack. Rescheduling takes more time as you have to maintain logic (dependencies). On the other hand, a schedule allows us to see how activities relate to each other. Based on estimates – which are part of any schedule by definition – one can easily tell when to expect what. Of course, with relation to time a schedule is only a prognosis. The sequence in a schedule, however, provides value by itself – allowing the involved to see how tasks refer to one another. A work organization tool. And a useful one at that.

Lists focus on work in progress.
Schedules focus on relations and dependencies.

Lists draw attention to the work at hand.
Schedules show us how late we are, in addition to the above.

For a one-man band a list is fine. That’s my view. Where there’s teamwork involved, I prefer a schedule. And so do my customers – when asked, I can instantly tell them not only how much work remains (same goes for backlogs), but what the estimated duration is, and what the key milestone dates are.

I am in favour of new approaches. Sometimes a new approach is just a stepping stone towards something better. Better than schedules.