Just-in-time Requirements Analysis (JITRA)

Introduction

Just-in-time requirements analysis (JITRA) is a BA approach based on lean/agile/kanban practices.

The 2 principles underlying JITRA are that requirements:

• Should ONLY be identified when they are needed; and
• Should ONLY be defined at the level of detail required

The first principle aims to optimize the timing of requirements; requirements should be delivered based on need rather than convenience (e.g.the  development team needs this next – versus – this feature can be specified easily).

The second principle aims to optimize the cost of requirements; superfluous detail is a waste of effort – and ultimately money.

Time and costing are often finite resources on a project. JITRA aims to optimize both from a requirements perspective.

Implementation

The most widely accepted framework for implementing JITRA principles breaks analysis down into 4 major activities:

• Initial Analysis
• Feature Set Analysis
• Story Analysis
• After-action Analysis

For a detailed description of each stage – please refer to: http://cf.agilealliance.org/articles/system/article/file/1007/file.pdf

Challenges

Teams that implement JITRA often face perceived challenges from a range of stakeholders:

• BA: “Without a buffer – requirements might not be ready on time. I don’t know how long it will take to analyse the requirements until I begin!”
• PM: “Without detailed analysis at the start of the project – how can I estimate the delivery date!”
• Developers: “Isn’t this just product leaving it until the last minute – and giving developers incomplete requirements!”

Although these perceived challenges could stop a team from experimenting with JITRA principles – there are strong advantages to the approach.

Advantages

• Agile: JITRA reiterates that the Business Analyst should work on features that can go straight into the backlog. This should provide the development team with a continuous flow of requirements and avoid a “BA bottleneck”. Additionally – as requirements don’t need to be fully specified upfront – JITRA enables requirement details to emerge during iterations.
• BA perspective: the further in advance of development that requirements are defined – the more likely they are to become out of date. This in itself will lead to rework and ultimately require more analysis effort. With JITRA all three of these issues should be addressed.
• Quality: the closer to delivery requirements can be left – the more information a BA has on which to build. This will lead to more valuable requirements.
• Developers: Product requirements typically exist at a high level – the BA provides the detail. One problem with this approach is that if a BA provides details far in advance – one or two specific (and probably minor/low value) detailed requirements could cause considerable development challenges. If the BA provides initial high level requirements – then the development team can present back a set of options for  detailed requirement – the development team can also quantify these options in terms of effort/risk/ technical elegance.
• PM: This approach requires a smaller upfront investment from the BAs. It also reduces waste from the requirements stage  – as there is less BA rework and less redundant effort.

Tags: Agile, Business Analysis, iiba, kanban, lean, Product Owner, requirements, scrum