Just-in-time Requirements Analysis (JITRA)
20 AprIntroduction
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.
Quantifying Agile
14 MarThere have been a number of attempts to quantify Agile adoption – i.e. to measure the “Agility” of a team. The appeal is obvious. If an Agile maturity model could be defined in a quantifiable manner, then it would be possible to grade individual teams:
Team 1
70% Agile – could do better.
Team 2
85% Agile – almost there!!
Team 3
No metrics.
The visibility this affords would provide Team 1 & Team 2 with tangible feedback and aspirational goals. To take this example further – if you were able quantify Agile adoption, then you would also be able to make informed strategic decisions and justify the existing development approach:
Let’s say you are the CIO. You pay £10,000 to bring in Agile trainers. One year later you want to measure the value of your investment. You ask Team 3 – who attended the training – and they say: “Yes we adopted it. We’re Agile”. You look at the team’s deliverables and see no improvement to their output. The quality, cost and timing for delivery have remained unchanged. Do you attribute this to Team 3 failing to implement Agile (i.e. due to a low level of adoption) or was Agile the incorrect approach for this team (i.e. due to the nature of the product another approach would have had greater efficacy)?
It’s certainly an interesting question. If you would like to quantify Agile adoption – you could look at the following resources:
i) Thoughtworks Agile Self Assessment: http://www.agileassessments.com/online-assessments/agile-self-evaluation
ii) Nokia Test (a.k.a The ScrumButt Test): http://jeffsutherland.com/nokiatest.pdf
iii) Agile Maturity Model: http://www.drdobbs.com/architecture-and-design/the-agile-maturity-model-amm/224201005
iv) Agile Artefact Audit: http://msdn.microsoft.com/en-us/library/dd997580.aspx
v) Agile Health Scorecard: http://illustratedagile.com/files/agile-health-dashboard-template.xlsx
Although the above techniques are valuable – there is a restriction when attempting to quantify Agile adoption. “Agile” is a concept; it is based on an aspirational manifesto: http://agilemanifesto.org/. The manifesto is descriptive (e.g. you should value customer collaboration) – rather than prescriptive (e.g. you should produce a customer collaboration tracker which should be reviewed biweekly with the PMO team). The reach of “Agile” as a concept/archetype means that measuring Agile adoption will always be an imprecise science.
Low Fidelity vs High Fidelity
9 MarLow fidelity assets are frequently employed on Agile projects. An example of a low fidelity asset is the production of basic wireframes/”back of the napkin” designs:
The advantage low fidelity designs is that they encourage feedback and corresponding design iterations – without the waste/overhead involved in high fidelity assets.
In terms of the Business Analyst role on Agile projects – low fidelity assets may include:
- User stories
- High level requirements (basic specification)
- High level acceptance criteria (basic user acceptance conditions)
What are the advantages of the Business Analyst employing the above mentioned low fidelity assets:
- They encourage a focus on the essential behavior of the system (MOSCOW must haves). This ensures the Minimum Viable Product (MVP) is documented early in the project lifecycle.
- Facilitates communication across a project. Low fidelity assets encourage feedback – they are much easier to present and convey than a 30 page BRD.
- Mitigates the risk of mistakes entering into detailed requirement specifications – assumptions can be identified earlier on.
- Descriptive vs prescriptive. The focus is on the high level functionality – this means that the technical solution is less constrained by non-essential elements of the product specification.
- Easily produced and maintainable – changes can be made quickly and with minimum effort. This sits well in the Agile world.
- Stand-alone pieces of work (features) can be identified – this enables backlog prioritization.
- Fidelity (i.e. detail) is added through participative iterations – documentation evolves through collaboration into a steady state.
Product Owners vs Business Analysts – MOSTly different roles?
14 FebThe MOST acronym (Mission, Objectives, Strategy, Tactics) can be used to describe the main differences between the Product Owner and Business Analyst roles on a project.
Mission
- This is the vision statement for the product. It should be concise and value driven.
- This will provide answers to the following questions: What is the intention and long term direction of the product? Who is the user-base/target market? What is the business benefit?
- Example: “We want to deliver the most popular Sports app in the World – with unparalleled journalist content”
- Responsibility of the Product Owner.
Objectives
- These are derived from the product mission. These are targets that will translate the product mission into reality.
- These will provide answers to the following questions: What goals will lead us to achieve our mission? What will need to be created? What will need to be changed? What will need to be acquired?
- Example: “We need to deliver live video streaming in the iOS app“
- Responsibility of the Business Analyst.
Strategy
- This is a description of how success will be achieved. This should describe the features and their prioritisation.
- This will provide answers to the following questions: How will the product scope be delivered across iterations? What is the Minimum Viable Product for release 1.0/launch? Which features are nice-to-haves?
- Example: “Pundit analysis, live video & match statistics are required for the first release – personalisation will be delivered in the second release of the app”
- Responsibility of the Product Owner.
Tactics
- These are derived from the product strategy. These are the deliverables that will be provided by the development team.
- These will provide answers to the following questions: How can we achieve tangible benefits in the next Sprints? What tasks need to be completed? How can work be grouped together logically & in terms of delivery?
- Example: “Provide live streaming of our CMS videos using Media Player”
- Responsibility of the Business Analyst.
Summary
Within MOST there are 2 definition activities (Mission and Objectives) and 2 planning activities (Strategy and Tactics).
- The Mission (high level product definition) is done by the Product Owner.
- The Objectives (detailed product definition) is done by the Business Analyst.
- The Strategy (high level product planning) is done by the Product Owner.
- The Tactics (detailed product planning) is done by the Business Analyst.
BANALysis – a new word for the BA lexicon
7 FebBANALysis
BA*NAL*y*sis
Noun
A combination of the words banal and analysis. Refers to situations where analysis is requested but not required.
Usage
“I’ve got to do BANALysis of a pagination component – UX have given all the different variants anyway!!”
“Can you do some BANALysis of this page of static links?”
“Can you do some BANALysis to MOSCOW these requirements with the senior stakeholders (who really want them all anyway)?”
Synonyms
unnecessary, tedious, obvious
The 3 Amigos – BA, QA and Developer
7 FebThe 3 Amigos (sometimes referred to as a “Specification Workshop”) is a meeting where the Business Analyst presents requirements and test scenarios (collectively called a “feature”) for review by a member of the development team and a member of the quality assurance team. The overall aims are to ensure:
i) COLLABORATIVE REQUIREMENTS: a common understanding of what needs to be built, business justification is conveyed for a feature, a project-wide sense of ownership.
ii) COLLABORATIVE TESTS: all teams members contribute to testing the quality of a feature, business & technical edge cases are identifed, testing restrictions are conveyed, test duplication within the team is reduced.
iii) READY FOR DEV CONSENSUS: Pull vs Push approach – features are pulled into a Sprint when they have been reviewed and accepted by the 3 Amigos. Features cannot be pushed into a Sprint – this reduces the risk of the team incorrectly assuming that a feature is ready for dev.
The general format of the 3 Amigo process is:
- A time boxed meeting (30 mins – 1 hrs max) is setup 1-2 Sprints before a feature is expected to go into development.
- 1 Developer + 1 QA are identified and invited to the meeting. These are expected to be the individuals who will develop and test that feature.
- The Business Analyst begins the meeting by introducing the feature to the Amigos. Why is the feature needed, is it like anything they’ve done before, what should it look like on the site?
- The Business Analyst presents the requirements (prepared prior to the 3 Amigos) – these are reviewed by the Amigos who provide feedback. The requirements should be updated in the session until the requirements are deemed “Ready for Dev”.
- The Business Analyst will then present the test scenarios (prepared before the meeting) – these are also reviewed by the Amigos. Feedback is incorporated until it is agreed that the test scenarios cover the feature’s expected behavior – this ensures good test coverage.
- The feature/specification is now “Ready for Dev” – it has been accepted by the developer and QA.
- Developer – asked to identify any tasks that need to be done pre-development e.g. do they need access to an endpoint, do they need to see variants of the visual design? These tasks are assigned and put on the current Sprint board.
- QA – asked to identify any tasks that need to be done pre-feature testing e.g. do they require access to a system, do they need mock data? These tasks are assigned and put on the current Sprint board.
- Estimate: the Amigos should have a common understanding of the requirements and the test scenarios (the “feature”). This is a good opportunity for the developer and QA to provide estimates.
Lessons we have learnt:
- The developer and QA involved in the 3 Amigo meeting should be the individuals who will develop and test the feature. We have explored the idea of “any developer/QA can be involved in the 3 Amigos and any developer/QA can then pickup the feature” – however we have learnt that maximum benefit comes from the Amigos being involved in a feature until its completion.
- The requirements and test scenarios should be maintained in a place where everyone has access. This gives individuals/stakeholders (even non-Amigos) VISIBILITY of the requirements and tests.
- What language should be used for requirements and test scenarios? Technical? Business? Plain English? We have found that DOMAIN language is the most useful … if you work in banking than all 3 Amigos should know what a derivative is – but not everyone is expected to know what a cron job is. If in doubt – maintain a glossary of terms.
Challenges:
- For the BA: although the BA still tacitly “owns” the requirements – part of the collaborative 3 Amigo process is a shared level of ownership. This can be difficult for a BA – as requirements are one of the main BA deliverables.
- For the Developer: there may be some resistance to reviewing requirements/test scenarios as these are “non–development activities”. In our experience the 3 Amigos process enables the developer to have greater visibility of the requirements, provide technical feedback and convey challenges/blockers.
- For the QA: similar to the BA – they may need time to adjust to the test scenarios being under common ownership.
- For the Product Owner: the Product Owner isn’t an Amigo. The process assumes that the BA represents the Product Owner/stakeholders. Once the requirements and test scenarios have been through the 3 Amigo process– it can be worth re-confirming them with stakeholders.
- For the PM: the 3 Amigo process limits what a PM can put into a Sprint – features are pulled into a Sprint by the team and not pushed by the PM. The BA can begin to take on some traditional PM duties: task breakdown (tasks are identified in the 3 Amigos), estimations (developer + QA estimates are provided in the 3 Amigos), limited Sprint planning etc.
- For the Agile enthusiast: to be a fully iterative process there may be “pre amigo” meetings – and complex features may require several sessions.
Agile Analyst 