Agile is a group of methodologies based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organising, cross-functional teams.
Sequential process in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of Planning & Initiation, Analysis & Design, Build & Test, and Deploying & Maintenance
A cyclic software development process. It starts with initial planning and ends with deployment with the cyclic interactions in between. Systems are developed through repeated cycles (iterative) and in smaller portions at a time (incremental), allowing software developers to take advantage of what was learned during development of earlier parts or versions of the system.
plan & initiate
Upfront Tasks
define the business need
description
Fully analyse and define the business problem/opportunity, its impact on the business, and the potential benefits being sought from a solution. This will be the basis for justifying why the project is being undertaken.
Agree on the business analysis methodology (e.g. waterfall, agile, six-sigma) to follow, based on the type of project and organisational standards. The level of tailoring and the combination of practices applied will determine the high-level deliverables from the analysis process, together with the nature and timing of the related tasks.
documents
There are no documents for this task.
determine the gap in capabilities
description
Identify business areas, outside of any system solution, which also need to be changed to meet the business need, for example, business processes, job design, system and information architecture.
documents
There are no documents for this task.
conduct stakeholder analysis
description
Identify and analyse all potential stakeholders for the proposed project or system. Stakeholders include anyone who has a vested interest in the product or system that is being developed. Stakeholders will have various levels of engagement throughout the project and will need to be communicated with along the way.
Determine and schedule the business analysis tasks that will be required. Prepare a plan that details how these tasks will be carried out, estimates of the work effort required, the sequence of events, and the resources that will be allocated to them. Include the nature and timing of stakeholder engagement in the plan.
Define the requirements management process, including how requirements are to be communicated, approved and changed. The plan will describe how requirements are to be recorded, what documents or artefacts are prepared from them, and how requirements will be prioritised.
documents
There are no documents for this task.
create stakeholder engagement matrix (RACI)
description
The RACI model enables the BA to assign responsibilities(accountable, responsbile, consulted, informed) to each identified stakeholder or project team member.
Evaluate and define the most viable solution-approach, to the level of detail required to define the solution scope and develop the business case.
documents
There are no documents for this task.
specify and model requirements
description
Specify requirements in multiple ways to define for solution designers and developers what is required of the solution to meet users’ needs; using a combination of textual statements, matrices, diagrams and formal models, in non-technical language.
Determine at a general level what is or isn’t going to be catered for in the solution (for example features). This is important for building the business case and managing expectations about the solution.
documents
There are no documents for this task.
create high level requirements
description
This is a template for specifying high level business requirements, defining scope, and communicating with stakeholders including sponsors, business owners and project managers.
Incorporate requirements that respect the needs of the end user/customer, including interaction behaviour, and goals for each persona that the system needs to cater for. This may include demonstrating wire-frame screen mock-ups to end users, incorporating feedback into requirements.
documents
There are no documents for this task.
create detailed requirements
description
This is a template for specifying detailed business requirements, defining scope, and communicating with stakeholders including sponsors, business owners and project managers.
Evaluate requirements to ensure they fulfil quality specifications and are sufficiently defined and structured to allow the technical teams to design, develop and implement an effective and efficient solution.
documents
There are no documents for this task.
build & test
BA tasks during design and build elaboration
communicate and publish requirements
description
Documentation and communication of requirements, throughout the project, to ensure they are correctly understood by all stakeholders and effectively implemented.
documents
There are no documents for this task.
manage requirements changes
description
Baseline and manage changes to the solution scope and requirements.
Create and maintain relationships between requirements and other solution components, such as test cases.
documents
There are no documents for this task.
deploy & maintain
Handover and transition
define transition requirements
description
Define the requirements of any transition tasks, including such things as organisational change, training, data migration, change over and decommissioning.
documents
There are no documents for this task.
validate and implement solution
description
Review the constructed solution to ensure it meets the business need and determine appropriate resolution of any defects. Continue the validation process through the implementation and transition process.
documents
There are no documents for this task.
evaluate solution performance
description
Assess the value of the deployed solution and compare the actual costs and benefits to those planned.
It is critical on an agile project to establish a clear vision (business drivers, outcomes) and have it shared between the visionary (business sponsor) and the agile project team.
The vision needs to be articulated in a simple manner so that it provides guidance for everybody on the team when making future decisions on scope and relative priority.
documents
There are no documents for this task.
recommend target solution architecture
description
A high level recommended target solution architecture, tools and technologies to be used by the project to provide initial direction for the team starting the project and ensure technical considerations are reflected in the business case pricing and planning.
documents
There are no documents for this task.
confirm project methodology
description
Agile means different things to different people so it is important that we understand the level of formality that is required from the software development process and explicitly communicate this to all stakeholders.
We need to agree which agile practices will be used and the impact this is likely to have on both the team and the business stakeholders that they interact with.
Bringing together the project team and jointly outlining the scope, high level design and schedule for the development effort.
appoint scrum master
description
The Scrum Master is the team facilitator, responsible for implementation and championing of the Agile Scrum process and ensuring that the team have everything they need to complete their tasks.
documents
There are no documents for this task.
appoint authorised product owner
description
The Product Owner is the primary business representative, responsible for implementing the business vision and project direction.
They manage the Product Backlog and prioritise the work to maximise Return on Investment (ROI) and ensure the development team build the right solution from a business perspective.
documents
There are no documents for this task.
negotiate working agreement
description
The Working Agreement is a common set of team rules which are established by the team and which they agree to commit to in order to maximise their ability to work together effectively.
This commitment is normally summarised in a brief written agreement and displayed in a prominent area of the team's working space. It is reviewed as part of the regular iteration retrospectives.
documents
There are no documents for this task.
negotiate analysis approach
description
The need for a dedicated Business Analyst and their level of involvement as part of the team will be heavily influenced by the Product Owner's domain expertise, key stakeholder relationships, their analysis skills and their availability to commit significant amounts of time to work directly with the development team.
TThe goal of each Iteration is to deliver potentially shippable working software.
The definition of "Done" is the criteria for accepting something as finished in support of that goal. There are normally at least three levels of "Done", these are:
Face to face communication and collaboration is the preferred mode of operation for agile project teams.
To be successful the whole team should therefore be co-located in the same project space and have a big visible workspace to easily communicate progress.
documents
There are no documents for this task.
prepare product backlog
description
The product backlog is a prioritised list of business features that need to be implemented by the project team. The product backlog includes both functional and non-functional requirements.
Release Planning is normally organised as a workshop, where the wider project team, both the business and development, engage in a story writing session to expand the high level business vision scope.
The list of stories in the expanded product backlog are then sized by development and prioritised by the business to create an initial release plan.
documents
There are no documents for this task.
iteration delivery (repeat as applicable)
Just in Time (JIT) planning, analysing, designing, building and testing the product in highly collaborative time boxed iterations (aka sprints).
attend iteration planning
description
Iteration planning is a workshop used to initiate an iteration, where the team meet to agree what stories can be done within the iteration time box and how long each delivery task is likely to take.
Customer tests verify that a story has been developed exactly the way that the Product Owner expected it to work.
documents
There are no documents for this task.
support story development
description
During an iteration the developer may have further questions about the detail of a story or the tester may want decisions on story acceptance criteria and test conditions.
documents
There are no documents for this task.
create appropriate documentation
description
A value from the agile manifesto recommends "working software over comprehensive documentation". This does NOT mean no documentation, but rather that working software is the primary measure of progress not specification and design documentation.
Agile promotes face to face communication and regular feedback cycles, which means typical project documents are replaced by conversation and rapid demonstration of code.
documents
There are no documents for this task.
groom the product backlog
description
The top priority Product Backlog items need to be reviewed so that the Product Owner is prepared and able to explain to the team the business reasons for the story.
documents
There are no documents for this task.
attend daily standup
description
The daily Scrum (also known as a daily stand-up) is a focused standing meeting between all team members which aims to optimise co-ordination towards the Iteration goal. The meeting should be timeboxed and take no more than 15 minutes. One of its goal is to eliminate the need for other meetings.
An agile team is optimally comprised of between five and nine people and includes anyone who is working on the Iteration Backlog tasks.
During an iteration, the team self-organises to best use the specialist and generalist skills of the team to complete the delivery tasks and meet the iteration goal.
documents
There are no documents for this task.
attend iteration review
description
The Iteration Review is a time boxed meeting held at the end of the Iteration where the stories that have been completed during the iteration are demonstrated to a wider project audience for review and feedback.
documents
There are no documents for this task.
attend iteration retrospective
description
The Iteration Retrospective is a timeboxed meeting that examines how the last Sprint went with regards to people, relationships, process and tools. It occurs after the Iteration Review and prior to the next Iteration planning meeting.
documents
There are no documents for this task.
release deployment
Incrementally releasing the product for production use.
conduct release review
description
The Release Review is a formal timeboxed meeting that occurs at the end of the Release Deployment phase. It is similar to an Iteration Review but focuses more on a demonstration of the end to end nature of the completed functionality and less on the detail. In addition the Product Owner summarises the final release deployment against the initial release plan, explaining any significant variations or discoveries that occurred on the way.
At a more formal level this may also involve PMO documentation and validation against the Business Case at a milestone level if the project involves multiple releases.
documents
There are no documents for this task.
conduct release retrospective
description
The Release Retrospective is a formal timeboxed meeting that occurs at the end of the Release Deployment phase. It is similar to an Iteration Retrospective but addresses a longer period of time - the full period of the release. It reviews the overall Definition of Done, the individual Iteration Retrospectives and solicits the current views of the team now that a releasable product has been delivered.
documents
There are no documents for this task.
inception
Project scope, risks and high-level requirements sufficient so that work can be estimated
conduct elicitation
description
Conduct the selected elicitation tasks to gather requirements.
Evaluate and define the most viable solution-approach, to the level of detail required to define the solution scope and develop the business case.
documents
There are no documents for this task.
define the solution scope
description
Determine at a general level what is or isn’t going to be catered for in the solution (for example features). This is important for building the business case and managing expectations about the solution.
documents
There are no documents for this task.
create high level requirements
description
This is a template for specifying high level business requirements, defining scope, and communicating with stakeholders including sponsors, business owners and project managers.
Working architecture that mitigates the top risks and fulfils non-functional requirements
organise requirements
description
Organise the requirements for the solution in a structured way, so that they give a comprehensive, complete and consistent view of the required solution from all stakeholders' (business and technical) perspectives.
Incrementally fills in architecture with production ready code produced from analysis, design and implementation and testing of the functional requirements
sprint planning meeting
description
The product owner describes the highest priority features to the team, who ask questions so they can determine which tasks they will move from the product backlog to the sprint backlog.Sometimes the lower priority items can be saved for the next sprint planning meeting. Together the Scrum team and the product owner define a sprint goal (short description of what the sprint will attempt to achieve).After the meeting, the Scrum team meets to decide how much they can commit to during the coming sprint. Negotiation with the product owner may take place.
Assess which requirements can be delivered in this phase, including those backlogged from earlier sprints. The Product Backlog is the master list of all functionality desired in the product. The Product Backlog is then allowed to grow and change as more is learned about the product and its customers. Product backlog items can be technical tasks or more user-centric with user stories. The product owner attends the sprint planning meeting with the prioritized product backlog. The team then negotiates the items for the coming sprint. Items are moved from the Product Backlog to the Sprint Backlog. Both high and low priority items could be selected for a sprint if they are related.
Organise the requirements for the solution to align to the sprint, so that they give a comprehensive, complete and consistent view of the required solution from all stakeholders' (business and technical) perspectives.
At the end of each sprint an informal sprint review meeting is held during which the Scrum team reveal or demo what they accomplished during the sprint. The project is assessed against the sprint goal determined during the sprint planning meeting.
documents
There are no documents for this task.
sprint retrospective meeting
description
The sprint retrospective meeting is held at the end of every sprint so that the team and ScrumMaster can discuss lessons learnt - what went well and what to improve in the next sprint. The meeting helps to adapt processes over time so that performance improvements can be made and 'bottlenecks' removed.(The product owner does not attend).
documents
There are no documents for this task.
transition
Delivers the system into the production operating environment
define transition requirements
description
Define the requirements of any transition tasks, including such things as organisational change, training, data migration, change over and decommissioning.
documents
There are no documents for this task.
validate and implement solution
description
Review the constructed solution to ensure it meets the business need and determine appropriate resolution of any defects. Continue the validation process through the implementation and transition process.
documents
There are no documents for this task.
evaluate solution performance
description
Assess the value of the deployed solution and compare the actual costs and benefits to those planned.
