Design
1. Business Analysis Planning
Business analysis planning must align to the overall project goal and objectives. The business analyst must coordinate the business analysis tasks with the activities and deliverables of the overall project.
The business analyst can leverage approaches and select techniques and tools that have historically worked well. This can include tasks to manage any risks that could reduce the quality of business analysis deliverables or impede task efficiency.
In order to plan the approach, the business analyst must determine the method to be used for completing business analysis work for a particular project using either a waterfall, agile or hybrid method. When planning the approach, the business analyst should consider the location of other team members and stakeholder, the type of project that the solution will deliver, techniques used to elicit requirements, the level of detail required for requirements and how to prioritise the requirements. Requirements will need to be managed through change control and clearly communicated to stakeholders.
Backlog Refinement – Backlog refinement is completed before the sprint planning meeting. The refinement ensures that there is enough clarification for items before sprint planning
Story Elaboration – Story elaboration is the lowest level of story decomposition.
Story Decomposition – Story decomposition allows the representation of a story at the appropriate level. Goals are managed via small stories to create value.
User Story – An informal description of a need or desire of a stakeholder or user of a system, when interacting with the system.
Management level and subject matter experts will represent the business as stakeholders during business analysis planning. They will be informed of the approach. Project managers and leads will also form part of the stakeholder group, for input into the project approach.
A Business Analysis Plan can be completed in as little as 3-5 days or take many months to develop. This is dependent on the project budget, time constraints for delivery, and complexity of the need being addressed both organisationally and technically (number of functions and people and number of applications and systems). Additionally the approach to the project (build vs buy, or process improvement) will impact the overall deliverables and as such the plan.
Planning is also not a one time event, plans should be revisited often to ensure the project approach is in line with any newly developed understandings.
As a guide – allocated 1.5 – 2 days planning for every month of project delivery. This will include your work breakdown structure or Work Plan.
2. Stakeholder Requirement Elicitation
Requirements elicitation is the practice of researching and discovering the requirements of systems from users, customers and other stakeholders.
The purpose of requirements elicitation is to thoroughly identify the business needs, risks and assumptions associated with the project.
There are many techniques that can be used to elicit requirements, such as workshops, brainstorming, interviews and questionnaires to name a few.
Prepare for Requirements Elicitation
The business analyst must have a comprehensive and accurate understanding of the project’s business needs to help safeguard against scope creep during elicitation. The proper stakeholders will need to be selected and elicitation techniques will need to be decided.
The business analyst must ensure that an adequate amount and mix of stakeholders have been secured for the duration of the project. During this time the business analyst must actively engage with the stakeholders to define requirements.
Brainstorming – The purpose of brainstorming with stakeholders is to produce new ideas. The business analyst should try to secure a representative from each participating stakeholder group in the brainstorming session. The business analyst is required to facilitate the session with the purpose of having the participants propose ideas and solutions. They must focus on the business needs and to avoid conversations that could lead to scope creep.
Document Analysis – Document analysis involves gathering and reviewing all existing documentation that is pertinent to the business objectives or may hold data that is relevant to the solution.
SWOT Analysis – Identify the market strengths, weaknesses, opportunities and threats.
Focus Group – Focus groups consist of stakeholders who gather to offer input on the business needs and its potential solutions.
Interviews – One-on-one interviews give the analyst the opportunity to discuss in-depth a stakeholder’s thoughts and to get their perspective on the business needs and the feasibility of potential solutions.
Requirements Workshop – Workshops facilitate increase in the collaboration between the stakeholders if conducted in the correct and methodical approach. It can promote the shared understanding as well.
Business Process Modelling – Business process modelling describes the sequential flow of work or activities. The process model describes the sequential flow of work across defined tasks and activities through an enterprise or part of an enterprise. The process models generally include the participants in the process, the business event that triggers the process, steps or activities of the process, path flows and decision points that logically link the activities and the process result.
Survey/Questionnaire – Surveys are useful for quick gathering from a large group of stakeholders/participants.
During stakeholder elicitation, the stakeholders will comprise of every business personnel who is involved with the processes that are being impacted by change. Depending on the size of the organisation, there may be select people nominated to represent others and become the stakeholder.
The time to deliver a Stakeholder Requirements Specification will be dependent on the number of functions and processes, the number and location of stakeholders, and any internal or external competing factors. As a guide, estimate 2 days effort for the establishment, capture, and documentation of a processes (including description and associated requirements). So for current state for 10 processes that is 20 days effort. Additional time for final editing and approval should also be calculated.
3. Conduct Product Review
The Product Backlog is a list of all known stories the team may deliver in future iterations. The product backlog is maintained iteratively and continuously, sometimes on a daily basis. Business analysts collaborate with the product owner to create the correct prioritisation of backlog items to deliver value rapidly and consistently.
The items which are going to be included in the more recent iterations are groomed before the planning meeting. Grooming is an open discussion between the development team and product owner. Where user stories are reviewed to clarify functionality, design considerations, integrations, and expected user interactions. Stories not yet scheduled for an iteration are left undeveloped to avoid unnecessary rework should requirements change. A well-maintained backlog provides enough work to the development team.
During the development stage, the business analyst clears the analysis-related roadblocks and uses cross-team competencies to deliver on the backlog items. Grooming the backlog removes the duplicate and irrelevant stories and helps team estimate the effort.”
Business Needs Assessment – Simply put, a business analyst performs business needs analysis to understand the needs of the business. It helps to understand the key issues and opportunities triggering the change needed by the business and targets the 6 interrogatives (who, what, where, when, how and why).
Business Model Canvas – A business analyst can develop a business model canvas that describes how the organisation creates, delivers and captures value for and from its customers. The business analyst can gather and plot information in nine building blocks. These building blocks describe how the organisation aims to deliver value. The business model canvas serves as a blueprint for implementing a strategy.
Templates relate to context and needs for the backlog items.
This step can be completed in a workshop format in 1/2 a day. Remember to ensure all resources, stakeholders, and any supporting information is organised prior.
4. Estimate Product Backlog
All the items in the product backlog are estimated to prioritise the user stories and plan the release. Estimation gives the product owner an assessment to plan the release(s). Estimation is based on knowledge, experience and complexity. Many enterprises use historical data to do a close approximation of the complexity.
Planning Poker – During planning poker, the product owner explains the story and then team estimates by assigning a number (usually Fibonacci series – 1,2,3,5,8, 13…). Each member of team assigns the story a number and then reveals it. Members with maximum and minimum estimates are allowed to explain their choice. The task is repeated until a consensus is achieved.
Relative Estimation– Focuses on comparing user stories by looking at their equivalent difficulty. This technique required the input of all members who are able to provide an assessment of the complexity of a story.
Silent Sizing – In this technique, different size cards are placed on table with stories by all the team. Then the cards are sorted from lowest to highest size card.
Spikes: Spikes are time-boxed research based exploratory technique to estimate the effort required to deliver a backlog item.
Spikes – Spikes are time-boxed research based exploratory technique to estimate the effort required to deliver a backlog item.
No specific template is required. Estimates are added as an additional information element for the backlog item.
No specific template is required. Estimates are added as additional information element for the backlog item.
5. Prioritise Delivery
The delivery is prioritised based on traceability to the business goals and objectives. Key considerations when prioritising the delivery components are the customer, value and the product vision as well as the complexity to deliver each component, and the team capacity. In case of conflicting prioritisation inputs, the business analyst uses negotiation and conflict resolution skills to reach a common ground. Hybrid projects may fail if prioritisation is completed based on personal, cognitive bias and does not consider the value perspective. Data driven prioritisation (based on tangible evidence) is replacing the cognitive bias to cross the chasm into evidence-based decision making
MoSCoW – MoSCoW (Must Have, Should Have, Could Have & Won’t Have) provides clarity on the prioritisation in line with the business value.
Minimum Viable Product (MVP). MVP identifies the minimum set of features which are required to deliver value to the customer. MVP can be put into practical production to gain market edge over competitor.
Purpose Alignment Model – Purpose Alignment Model is used to assess idea in terms of value for customer. The illustration below, (courtesy: IIBA’s Agile Extension v2.0), is an example of purpose alignment model:
No specific template is required.
This step can be completed in a workshop format in 1/2 a day. Remember to ensure all resources, stakeholders, and any supporting information is organised prior.
6. Develop Product Roadmap
A Product Roadmap is defined as a document which lists product capabilities and identified releases or the development path. These product roadmaps are strategic roadmaps and are completed prior to an initiative moving forward to provide direction and oversight on the value to be delivered now and later.
In some cases, product roadmaps come down from management (usually referred to as a stakeholder-driven roadmap).
Typically the Product Manager is responsible for maintaining and updating the product roadmap. One significant drawback for product roadmaps is that if there is constant changing, then the shared understanding of the value and communication management becomes a challenge.
Product Roadmap – A product roadmap is used to provide an overview of the sequence for delivery, dependencies on delivery, and to communicate expectations with internal and external users.
This step can be completed in a workshop format in 1/2 a day. Remember to ensure all resources, stakeholders, and any supporting information is organised prior.
7. Creating User Stories
During requirements elicitation user stories are captured. At the second stage of the Hybrid design stage the highest priority user stories are refined, since understanding of the value is clearer (hence commencing designing!). The refined user stories with associated acceptance criteria and designs are an input to the development stage ceremonies. It is important for the business analyst to define stories that are clear and understood by all parties so as to promote a shared understanding of the value.
A user story should follow the INVEST criteria to ensure quality.
(I) Independent: represents a feature which can be delivered independent of other features.
(N) Negotiable: the team can negotiate how to deliver (SCRUM framework)
(V) Valuable: value to the customer.
(E) Estimable: implementation effort can be estimated.
(S) Sized appropriately: A complex user story which requires multiple iteration for completion can confuse the team.
(T) Testable: can be validated against acceptance criteria.
The business analyst iteratively discusses the user stories with stakeholders to confirm and validate them.
Story Mapping – Story mapping is used to assist with the prioritisation. It creates flow of usage and helps understand the functionality.
Story Elaboration – Story elaboration is the lowest level of story decomposition.
Story Decomposition – Story decomposition allows the representation of a story at the appropriate level. Goals are managed via small stories to create value.
User Stories – An informal description of a need or desire of a stakeholder or user of a system, when interacting with the system.
Business analysts consult business stakeholders directly (in the absence of a product owner), or discuss the user stories with the product owner to ensure these user stories can be traced back to problem solution, need satisfaction or opportunity realisation.
User Stories and Acceptance Criteria will need to be developed to a deliverable level. As this is being conducted from the developed specification the expectation will be that the complete backlog has been defined as a result of these activities. As such, the amount of time allocated to this activity will depend on the complexity of the previous specification. Allow 1 – 4 weeks depending on this factor.
8. Identify Acceptance and Evaluation Criteria
Acceptance and evaluation criteria are part of a user story. While developing these criteria, agile analysis considers the possible scenarios to test the user story. The objective is to make the testing as fool-proof as possible. Clear and well written criteria will subsequently be helpful in the development stage.
In some organisations, this activity is deferred in the designing stage and considered part of the development stage instead, though this may impede agile development. It is the responsibility of a business analyst to collaborate with stakeholders and include the acceptance and evaluation criteria in all user stories.
Systems thinking skills and critical thinking skills are useful in this task.
Acceptance and Evaluation Criteria – This technique creates the criteria which must be fulfilled to achieve stakeholder approval or satisfaction. It may be a checklist.
Use Cases and Scenarios – Use cases provide insights into how a user interacts with the system. Most common main flow scenarios are identified along with the exception and alternative scenarios.
The product owner is a key stakeholder for this activity
As above, User Stories and Acceptance Criteria will need to be developed to a deliverable level. As this is being conducted from the developed specification the expectation will be that the complete backlog has been defined as a result of these activities. As such, the amount of time allocated to this activity will depend on the complexity of the previous specification. Allow 1 – 4 weeks depending on this factor.
9. Further Estimate Product Backlog Items
The items that are deemed highest priority by the product owner, that have now been further refined with acceptance criteria, need to be further estimated to support delivery. Estimation gives the team the ability to identify a lower level of relative estimation to ensure the development stage is not over or under burdened. Like the discovery stage, estimation is based on knowledge, experience and complexity.
Planning Poker – During planning poker, the product owner explains the story and then team estimates by assigning a number (usually Fibonacci series – 1,2,3,5,8, 13…). Each member of team assigns the story a number and then reveals it. Members with maximum and minimum estimates are allowed to explain their choice. The task is repeated until a consensus is achieved.
Relative Estimation – Focuses on comparing user stories by looking at their equivalent difficulty. This technique required the input of all members who are able to provide an assessment of the complexity of a story.
Silent Sizing – In this technique, different size cards are placed on table with stories by all the team. Then cards are sorted from lowest to highest size card.
Spikes: Spikes are time-boxed research based exploratory technique to estimate the effort required to deliver a backlog item.
The product owner is a key stakeholder for this activity as well as representatives from each discipline.
No specific template is required. Estimates are added as additional information element for the backlog item.
This activity can be run as a separate session to tagged on to the back of the previous elaboration step. Allow 30 mins per sprint week length to complete.