DSDM CONSORTiUM DSDM CONSORTiUM AgileBA The Handbook for Business Analysts Extract The Lifecycle In An Agile Project www.dsdm.org
This Extract from AgileBA, The Lifecycle in an Agile Project, is based on a subset of Agile Business Analysis Handbook is intended for promotional use only and not to be taken out of context. Readers wishing to know more about or use the AgileBA Handbook are invited to visit the website at www.dsdm.org where the full version of the Handbook will be published in 2014. Copyright 2013 Dynamic Systems Development Method Limited DSDM, DS M Atern and AgilePM are registered trade marks of Dynamic Systems Development Method Limited in the United Kingdom and other countries. AgileBA is a trade mark of Dynamic Systems Development Method Limited in the United Kingdom and other countries. D All rights reserved. Applications to reuse, reproduce or republish material in this publication should be sent to the address below or by email to info@dsdm.org Published by the DSDM Consortium This Extract first printed September 2013 For further information regarding this and other DSDM products please contact: DSDM Consortium Henwood House Henwood Ashford, Kent TN24 8DH, United Kingdom Website: www.dsdm.org THE REQUIREMENTS LIFECYCLE IN AN AGILE PROJECT 1. Introduction The Agile (DSDM) approach to requirements is to clarify the project objective and Business Case and then to define requirements, at a high level only, early in the project. The definition of detailed requirements is deliberately left until just before it is needed: just before that particular aspect of the solution is developed and built. This avoids waste and rework. It also ensures that the product can evolve to reflect the needs of the business at the time of solution-building. It allows for learning during the project and for change to be embraced, rather than being treated as a problem. However, the risk inherent in this incremental approach to defining requirements is that an inconsistent or internally-conflicting set of requirements could evolve. This is where the skills of the Agile BA are essential. The Agile BA must facilitate the evolution of requirements from high level objectives down to low-level detail at the appropriate time, whilst keeping the consistency and focus, completeness and prioritisation of the requirements set as a whole. The traditional Business Analysis discipline of Engineering is still appropriate and can be applied in an Agile way. Engineering acknowledges that each requirement has a lifecycle of its own, from its initial elicitation, through its analysis and validation to its eventual incorporation into the solution, or its rejection or de-scoping. In this chapter we look, from an Agile perspective, at the Requirement Engineering lifecycle of: Elicitation Analysis Validation Management and documentation Production: Emily Ruffle Artwork by Debbie Cole Printed in the United Kingdom by Buckland Media Group Limited, www.buckland.co.uk Elicitation Validation Management and documentation of requirements Analysis Figure 11.1 We see the approach the Agile BA takes, both pre-project and throughout the DSDM lifecycle, including post-project benefits assessment. We explore how the Agile BA will ensure that the requirements form a consistent and coherent whole. We see how Agile requirements are captured and recorded appropriately, as they evolve and expand in detail. We also consider the use of key Agile practices in this process.
2. The role of the Agile BA in handling requirements The responsibilities of the Agile BA within a DSDM project are to ensure that the business needs are properly analysed and are correctly reflected in the Evolving Solution. On a day-to-day basis, the Agile BA manages the documentation and products related to business requirements. They ensure that business implications of day-to-day decisions made by the Project-Level and Solution Development Team (SDT) roles are thought through. They keep requirements aligned to the purpose and objectives of the project, as well as the needs of the end-users and customers of the product. They are the facilitator, negotiator and mediator in conversations between business and technical roles. They have the skills to make visible the implications of prioritisation and the decisions to include or de-scope requirements. They become the central point of communication about what is required, and why, for both the Project level and SDT roles. The role of the Agile BA is to be the guardian and champion of the requirements. They do not own the requirements (it is important that ownership is accepted by the business representatives). However, the management of a clear, useful and incrementally-evolving requirements set is the responsibility of the Agile BA. As we saw in Chapter 1, the role of the Agile BA may be wider than the Agile project; they may also work in a corporate planning framework or a strategic programme. Engineering activities are valid for requirements work at any level. 3. The Lifecycle of a Requirement A requirement may begin life as an idea, a need, or a statement of a problem to be addressed. The first requirement of the project is its objective, expressed in outline in the Terms of Reference (TOR) and clarified during Feasibility. From this point, a hierarchy of requirements begins to emerge, expanding from the project objective to Major Themes, to Epic Stories (High-level ) of the Prioritised List (PRL) and down to the detailed User Stories elaborated during Exploration and Engineering. Business Strategy / Need 3.1 Elicitation Elicitation is the identification, extraction and capture of the requirement. In an Agile project this is typically achieved by: face-to-face conversations; observation; Facilitated Workshops; demonstrations of working elements of the solution; scenarios Modelling and Prototyping. These approaches can work together. For example, scenarios can bring to life business situations and can provide the basis for prototyping and testing. Storyboarding scenarios can be seen as a form of low fidelity prototype. Elicitation is not a trivial task; many users do not know clearly what they do want from the solution, until they see something. Also, knowledge that the users have may be: Explicit: easy to explain and capture; Tacit: hard to capture because people do not even know that they are holding it Semi-Tacit: where things are taken for granted, or only held in short term memory and therefore not really remembered or known. Many requirements are omitted because they are taken-for-granted or merely forgotten. The Business Analyst is a detective, uncovering the true requirements as the project progresses and using Agile practices and business analysis skills to identify gaps and disconnects. 3.2 Analysis P R O J E C T Business Objectives / Goals Project Objectives / Goals Project Business Strategic Business Case Project User Project Business Case Objectives and Themes Project Solution Epic Stories High Level User Stories User Stories Detailed User Stories Each requirement needs to be analysed to clarify its meaning and to determine whether it is: realistic; unambiguous - clear enough to be understood by different stakeholders; feasible technically, financially, socially; congruent with the business goals; relevant to the objectives of this project. Its dependence on other requirements must be analysed and made visible and any potential conflicts and duplication with other requirements must be resolved. The Agile BA will analyse each requirement and also facilitate the prioritisation of each requirement by the business. The Agile BA must be a negotiator, as there is a good chance that some requirements will be in conflict with each other, which may result in conflict between the stakeholders who own them. The Agile BA will mediate to reconcile these conflicts and differences, often by using facilitation skills in a Facilitated Workshop to bring together the parties in conflict. Agile techniques such as hands-on prototyping, role-plays, demonstrations and modelling can be helpful in uncovering tacit and semi-tacit information. Figure 11.2 Every requirement passes through the following stages: - Elicitation - Analysis - Validation - Management and Documentation Solution can emerge as business requirements, technical constraints, technical opportunities, business rules. The Agile BA may also find that they are stated as solutions in the first instance. These need further analysis to discover what benefit they must give. If requirements are too solution-oriented, they may place unnecessary constraints on the Evolving Solution, removing some of the flexibility needed by the SDT when they come to evolve that piece of the solution. can be functional, describing the features needed or what the solution must achieve. Others can be nonfunctional and address the end-product s required behaviours such as performance, usability, access security, archiving, backup, security, availability, maintainability, robustness. The completeness of the requirements from a functional and non-functional perspective, and the evolution from business requirement to technical implementations of those requirements is part of the analysis the Agile BA must perform. These requirements lifecycle stages are not serial, with Management and Documentation happening throughout. Elicitation and Analysis run together iteratively, overlapping with Validation as the requirements become more mature.
3.3 Validation Validation applies to both the individual requirement and to the whole set of requirements for the increment and for the project. Since requirements do not emerge in detail until just before they are built, a high-level view of the requirements and their dependencies needs to be expressed and communicated. Modelling can assist the process of defining the increments into which the project is divided, and can show dependencies, in order to minimise unexpected overlaps and reduce risk. must also be testable. Even at the very early stage of identifying requirements, the Agile BA will ensure measurable acceptance criteria for each requirement are agreed with stakeholders. This way, they will confirm what is needed for the requirement to be successfully implemented. 3.4 Management and documentation 3.4.1 Documentation Agile has a reputation for being light on documentation, but why do requirements need to be documented? Documentation is typically for at least one of four purposes: - To pass a message from one person / set of people to another; - To record information now, whilst we know it, for later when we may have forgotten it; - To help us to manage complexity; - To prove we have done something. In an Agile situation, the first three are still valuable. The fourth should not be quite as necessary in an Agile culture of trust, as it would be in a culture where the fear of failure predominates. However, this may still have relevance for audit and compliance purposes, in highly-regulated industries, for example. The actual needs of such an audit purpose should be investigated as many situations do not need the volume of documentation which was customarily provided in traditional waterfall projects. 3.4.2 Management Once a requirement has been identified, its inclusion within the final product or its de-scoping should be traceable, along with the rationale for this, both horizontally (from beginning to end of the project); and vertically (from the overall business goal it is addressing to the realisation of this). This enables the stakeholders of the project to understand what is, and is not, contained within the final solution. It helps to prevent requirements being missed by accident or new requirements being brought into the project without consideration of their impact on others or on Timebox and project timescales. This is not to prevent change Agile projects embrace change, even late in the process. However this change needs to be introduced in a considered way, with an appropriate level of change control not too heavy, but not non-existent. The Agile BA will be the guardian of the project requirements and the related PRL from this perspective, although decisions on whether or not to accept change will ultimately lie with the Business Visionary. IT tools to support the management of requirements, from first capture through to integration and delivery of the evolving solution, may be necessary and useful. However, tools alone are hardly ever the solution to requirements problems or poor requirements engineering. Visibility of the requirements as they progress through the lifecycle is the Agile approach to communication and dissemination of information, through Information Radiators such as wallboards and permanently-visible large screens, and through collaborative practices such as daily stand-up meetings and Facilitated Workshops. 4. within the Agile (DSDM) project Lifecycle The pattern of eliciting, analysing, validating and managing/documenting requirements is embedded at every phase of the DSDM lifecycle. However, the level of detail is different, progressing from the project objective and the very high level requirements defined at Feasibility, through to the most detailed level, which emerges timebox by timebox during Exploration and Engineering. For the first point above, the documentation needed will be reduced if the team (including business roles) can be co-located. For the second point, documentation is reduced in an Agile situation as the detail is only elaborated just before it is needed, so the timeframe to remember detail is short. For the third point, complexity is reduced by the incremental approach to solution evolution and the feature-focused timeboxes. These aim to deliver a complete, cohesive, small and potentially-implementable segment of the solution in a short timeframe. Thus documentation in an Agile project should be sufficient for purpose, and only that. The two golden rules of Agile documentation are: - Do not document unless it is useful to someone specific (a 50 page document that no-one actually reads is not proving useful to anyone); - document in a way that is useful to the recipient (ask how this will be used, and by whom). Pre-Project Feasibility Foundations Very High Level (Objectives and Themes) High Level Prioritised (Epics and User Stories) The level of documentation required depends on the ease of communication of team members. Co-located Agile teams need less detail when writing down User Stories than distributed teams, for example. However, the documentation of requirements may also be needed to act as a basis for support documentation, for the end-users of the product and also for those supporting the end-users (a Service Desk, for example) and where there are regulatory/compliance/audit obligations to meet. In this case, the documentation needs to be sufficient to satisfy that need. Deployment The documentation related to requirements is used by both users and technical team members. The language, therefore, must be clear, with agreed terminology and accessible to all disciplines involved. Exploration The documentation of requirements in an Agile project is an incremental, evolving activity. Post-Project The information needed about a Requirement / User Story at any point is typically: A unique Requirement / Story Identifier; a short recognisable name; Description; Acceptance criteria; Source; Owner; Author; Priority; Rationale/Benefits; Business Value; Related or dependent requirements/ User Stories; Version control/status. This information helps to classify, identify and manage the requirement and its emerging detail. It also supports configuration management and change control. Detailed (Detailed User Stories) Figure 11.3 Engineering
Below, the involvement of the requirements lifecycle within each project lifecycle phase is considered, together with the use of DSDM practices. 4.1 Pre-project Pre-project activity supplies the Terms of Reference (TOR) for the project. The TOR will identify the problem to be solved or opportunity to be addressed. This is effectively the first, very high level requirement. 4.1.1 Elicitation A strategic Business Analyst (a different person from the allocated project BA) may have been involved in the production of this, and the project s Agile BA will need to understand its context. 4.1.2 Analysis The pre-project analysis, or results of a programme of which the project is a part, may produce a high-level scoping diagram to set the objective in context 4.1.3 Validation The Business Sponsor, Business Visionary and Business Analyst, and later the Project Manager, need the TOR to be a clear-enough justification for the project to be considered during Feasibility. 4.1.4 Management and Documentation The TOR should be documented (one or two pages at a maximum) with high level objective, benefits, costs, risks and any initial assumptions. DSDM has a product definition for the TOR, along with other documents mentioned later. 4.2 Feasibility The purpose of Feasibility is to provide a high-level overview of the project, enough to assess whether the project is worth doing, from both technical and business points of view. During Feasibility, a very high level set of requirements will be elicited (probably no more than ten or so of these - too many would indicate too low a level of detail for the purpose of Feasibility). These requirements are at the level of major Themes or very high-level features. They need to be just enough to: Act as the headline guidance for the project scope. Each theme or feature will typically expand during Foundations into lowerlevel detail; Give enough detail for a broad estimate of project size, with the acknowledgement that the accuracy of any estimate is within a broad range. Allow a first consideration of priorities, although at this level they may all appear to be Must Haves. 4.2.1 Elicitation At Feasibility, the Agile BA is trying to establish a shared vision for the project with the Business Visionary and Business Sponsor and between other stakeholders. Themes and features are typically elicited by face-to-face conversations and Facilitated Workshops. A Feasibility Prototype may be used to clarify what is envisioned. The formulation of a simple, one sentence project objective, which sits above the themes and features will form a useful focus for the whole project. 4.2.2 Analysis Themes and high-level features are analysed to establish dependencies and conflicts. The Agile BA would use Modelling to make the structure of the functions visible. Facilitated workshops would be used to enable negotiation of the high level features and their priorities (MoSCoW prioritisation). Acceptance criteria (very high level, but measurable) would be established for each Theme or Feature. The Feasibility Assessment will contain these Themes / Features as the embryonic Prioritised List. 4.2.3 Validation The project team during Feasibility is: the Business Sponsor, Business Visionary, Technical Co-ordinator; Project Manager and Business Analyst. Validation and acceptance of the very high level Themes and Features may also need approval of a wider set of stakeholders. These may be a steering committee, or an investment appraisal body within the organisation, for example. Whilst negotiation and agreement of the major Themes and their prioritises may happen during a Facilitated Workshop, a more formal Quality Review meeting (described later) may be chosen, to baseline and effectively sign off the Feasibility Assessment. 4.2.4 Management and Documentation The Themes / Features should be recorded appropriately and visibly for all stakeholders. This is the embryonic Prioritised List (also often called a Product Backlog in other Agile approaches). During Feasibility, it needs to be at a level which is just sufficient for purpose. It will form the top level of the hierarchy of requirements which will emerge later. Modelling and diagramming will aid the visibility and clarity of this hierarchy and set out the context and scope. 4.3 Foundations The team during Foundations includes Solution Development Team roles, which are needed to estimate work required and produce the Delivery Plan. During Foundations, it is important that the whole team is aware that there is more work needed on requirements than one pass of requirements capture in a Facilitated Workshop! The themes from Feasibility each need be expanded to a further level of detail, to form high-level requirements (Epic stories). During Foundations, business analysis work will be needed, to provide a clear structure (firm foundation) on which to work during Exploration and Engineering, when Epics are split into lower level User Stories. Foundations also provides the testing strategy (as a part of the Solution Foundations documentation) against which validation will be performed. 4.3.1 Elicitation The Agile BA will organise Facilitated Workshops to expand the Themes and Features into high-level requirements. These workshops are often supported by modelling and prototyping, which the Agile BA will do. The participants will be selected as appropriate for each workshop, but will draw from the Business Sponsor, Business Visionary, Technical Co-ordinator, Project Manager, the Solution Development Team, Business Advisors and a wider group of stakeholders. 4.3.2 Analysis After eliciting requirements, the Agile BA will work face-to-face with appropriate stakeholders to define each requirement further and analyse whether it is realistic, feasible, ambiguous or conflicting with, or duplicating other requirements. They would also gather more information about the business goal served and the value of the requirement. The roles of Business Ambassador(s) and Business Visionary have the empowerment to speak on behalf of the different business areas. During Foundations, Epic user stories are established. Facilitated Workshops can be used to clarify and share requirements information and to resolve conflicts and overlaps. Acceptance criteria will be established at a high level against each requirement. Prioritisation is also done at this point, using Facilitated Workshops and MoSCoW prioritisation. 4.3.3 Validation Once a Prioritised List (PRL) has been established, this needs to be validated by the Project Level and SDT roles, and possibly a wider group of key stakeholders. It is recommended that the PRL is formally agreed and baselined at the end of Foundations, by Quality Review. This then acts as a clear statement of the scope, upon which estimates during Foundations are made. Whilst the Agile approach is to embrace change, it is very powerful focus for the project to agree the PRL in this formal way. When change comes along during the project, which changes the breadth of the project, it is easier to assess its impact. The Epic Stories on the PRL act as the headlines from which more detailed requirements are elaborated during Development Timeboxes. Even If the project is exploratory, the PRL will set parameters related to the breadth of scope and the benefits the project was funded to achieve. A Solution Prototype may also be produced during Foundations and is a powerful way to elicit and validate requirements.
4.3.4 Management and Documentation The main requirements product of the Agile BA during Foundations is the PRL. This becomes a central document for the remainder of the project. The requirements on the PRL should describe what needs to be achieved, rather than exactly how it will be done, to allow flexibility during Exploration and Engineering to focus on the business need and its achievement. The PRL should be at a sufficient level of detail to allow the SDT to estimate for the Delivery Plan, showing a schedule of expected timeboxes for at least the first increment of delivery. 4.4 Exploration and Engineering Business analysis is a defined part of the SDT work within each stage of iterative development within the Development Timeboxes. The Agile BA facilitates the expansion of the Epic Stories of Foundations into lower-level User Stories, which guide development and testing. Facilitated by the Agile BA, each User Story will be elaborated via demonstrations, prototypes, models and face-toface communication within the SDT. 4.4.1 Elicitation During Development Timeboxes, the detailed requirements (User Stories) need to be discovered. This will mostly be through face-to-face discussions and prototyping. Solution Developers, Solution Testers and Business Ambassadors work together to concurrently expand the requirements detail and build the product. The Agile BA will capture the emerging detail, expanding the PRL, timebox by timebox, with appropriate lower level detail and detailed acceptance criteria. 4.4.2 Analysis As requirements detail emerges, these lower level requirements will need to be prioritised by the Business Ambassador(s) and Business Visionary and agreed within the SDT. The business value of the detailed requirements also needs to be assessed, priorities agreed and estimates made of the effort required to complete them. The Agile BA will facilitate this conversation within the team and keep the link to the higher level requirements, processes and data within the solution domain. The BA will model the structure of the requirements (story mapping) and keep this visible to the team, so that the impacts of day-to-day decisions can be seen. 4.4.3 Validation The Agile BA will work to keep the focus on the business case and higher level themes and features, as lower-level requirements and acceptance criteria are defined. During Engineering, the focus is on the validation of the finished, working solution. Frequent demonstrations of elements of the solution to the project team and a wider stakeholder group will be a key part of this, facilitated by the Agile BA. The acceptance criteria will drive test scripts. Decisions will be needed on: The definition of Done the criteria for the product to be considered acceptable and ready for deployment; test coverage what is being tested at each demonstration or testing session: functional aspects, usability, non-functional, performance. requirements for which the solution has now been built and tested (and is about to be delivered) back to the Business Case. They will make visible the benefits which should now be able to accrue to the Business Visionary, and to those who will receive and use the solution. Post-Project, the documentation of requirements from the project, plus the Business Case will be used to assess the level of implementation of the requirements. Post-Project benefits assessment is likely to be achieved using a Facilitated Workshop, which the Agile BA may facilitate. 5 Agile Practices MoSCoW prioritisation, Facilitated workshops, Modelling and Prototyping, Iterative Development and Timeboxing have been considered above, alongside the project lifecycle. One additional technique, useful as a collaborative way of agreeing and validating a set of requirements, is the Quality Review meeting. 5.1 Quality Review meetings Quality Review meetings are a formal meeting to study a product (here a set of requirements) and identify errors or defects, which will be corrected outside of the meeting. In brief, the process is as follows: Plan the review: the review team is selected, and the time and venue agreed. Preparation for review: the chairperson for the Review will distribute copies of the document to all parties, who should return a Queries list before the meeting. The meeting: the meeting allows the AgileBA to talk through the requirements item by item and for reviewers to respond. It should be noted that the meeting is not the place to identify the solutions or fixes to problems. At the end, the chairperson will agree with all reviewers what follow-up action is to be taken for any errors found, by whom and by when. Follow-up: follow-up action may be needed because the requirements were not acceptable and a further review may sometimes be needed. At the end of the review process, by agreement, the document can be signed off and baselined, to provide a firm foundation for further evolution of the requirements during Development Timeboxes. 6 Summary Agile Engineering allows requirements to follow a controlled, incremental process of decomposition and elaboration, from a high level objective, themes and features, through to high-level prioritised requirements, to fully-evolved requirements present in prototypes and the final solution. Each requirement has a lifecycle of Elicitation, Analysis, Validation, Management and Documentation. Following this helps the Agile BA to ensure the focus on requirements is appropriate at the different project lifecycle phases. It also helps to mitigate the risk that an inconsistent or internally-conflicting set of requirements could evolve. The Agile BA facilitates the evolution of requirements from high-level objectives down to low-level detail, whilst keeping the consistency and focus, completeness and prioritisation of the requirements set as a whole. Agile DSDM practices form a key part of this process, facilitated by the Agile BA. 4.4.4 Management and Documentation During Exploration and Engineering, detailed requirements (User Stories) are documented in the prioritised requirements list (PRL). Any modifications or further sub-divisions of the requirement should always be traceable back to the higher-level requirements. It is also important during Exploration and Engineering to record those Should Have and Could Have requirements or features that have been traded out or dropped and hence have become Won t Have requirements. The PRL can be a useful tool for recording errors and bugs discovered when testing the solution so that they can be prioritised and considered in the context of the overall requirements. 4.5 Deployment and Post-project By Deployment, the elicitation and analysis of requirements is complete. Any specific requirements related to the deployment of the solution should have been captured during Exploration and Engineering and fed into the Deployment Planning. The validation activity here is to ensure that requirements documentation is sufficient for both support of the solution in live usage, and for the Post-Project benefits assessment to be done. In the first part of Deployment, the Agile BA will link those