Embed Size (px)
Citation preview
(Professional Business Analyst Training
organisation)
Acceptance criteria , Business value and Complexity point in Scrum
Acceptance criteria: Acceptance criteria in scrum is important because only when it is clearly defined upfront it avoids surprises at the end of the sprint and ensure high level of customer satisfaction. It has the condition that a software product must satisfy, It states pass/fail result for all the functional or nonfunctional requirements applicable at Epic , feature and story list .
Traditional BA (Waterfall) Agile BARequirements are documented in Use Cases,Business Requirements, Functional requirements, UI Specifications, Business Rules.
Requirements are documented in Epics, User Stories and optionally Business (or Essential) Use cases.
Focuses on completeness of requirement and spends time in ensuring the requirement is unambiguous and has all the details.
Focuses on understanding the problem and being the domain expert so that s/he can answer questions from the development team swiftly and decisively.
Focuses on getting a ‘sign off’ on the requirements.
Focuses on ensuring the requirements meet the currentbusiness needs, even if it requires updating them.
Often there is a wall between the BA/Business and the Development team.
Agile BA (Often called as Product Owner) is part of the team.
Tends to dictate solutions.Has to remain in the problem domain, leaving the development team ‘space’ to explore different solutions.
Long turnaround. Quick turnaround.Focus on what the requirements document said. In other words, output (Artifact) is a well written thorough requirements document.
Focus on the functionality of the developed software. In other words, output (Artifact) is the software that meets thebusiness needs.
• When to define acceptance criteria: Acceptance criteria has to be defined before implementation begins , as in such scenario we are more likely to understand user needs and expectations rather that the development reality.
oWhat makes good Acceptance Criteria?Acceptance criteria should be clear and simple without any ambiguity regarding the outcome.As acceptance criteria is referred by testers and translate them into automated test cases to run as a part of continues integration build.
The criteria should be independent of the implementation, and discuss WHAT to expect, and not HOW to implement the functionality.
" Given/When/Then " format is helpful way to specify criteria
"Given some precondition When I do some action Then I expect some result"
When writing acceptance criteria in this format, it provides a consistent structure. Additionally, it helps testers determine when to begin and end testing for that specific work item.Scenario’s where in it is difficult to construct criteria using the above format people prefer Verification checklists.
Business Value:Business value is mainly calculated to prioritize the product back log
Business value is based on below sources:1. Market value :It helps us to identify which feature to develop first so that client can firstly sell more units and secondly get higher price.2.Reduce Risk:To what extent will this story if completed in first instance allow us to penetrate the app/product into the market and reduce the risk of failure and helps gain competitive advantage to client.In product development not all the features are created equal , so prioritizing the features effectively can deliver a quality output.
Traditional BA (Waterfall) Agile BARequirements are documented in Use Cases,Business Requirements, Functional requirements, UI Specifications, Business Rules.
Requirements are documented in Epics, User Stories and optionally Business (or Essential) Use cases.
Focuses on completeness of requirement and spends time in ensuring the requirement is unambiguous and has all the details.
Focuses on understanding the problem and being the domain expert so that s/he can answer questions from the development team swiftly and decisively.
Focuses on getting a ‘sign off’ on the requirements.
Focuses on ensuring the requirements meet the currentbusiness needs, even if it requires updating them.
Often there is a wall between the BA/Business and the Development team.
Agile BA (Often called as Product Owner) is part of the team.
Tends to dictate solutions.Has to remain in the problem domain, leaving the development team ‘space’ to explore different solutions.
Long turnaround. Quick turnaround.Focus on what the requirements document said. In other words, output (Artifact) is a well written thorough requirements document.
Focus on the functionality of the developed software. In other words, output (Artifact) is the software that meets thebusiness needs.
Traditional BA (Waterfall) Agile BARequirements are documented in Use Cases,Business Requirements, Functional requirements, UI Specifications, Business Rules.
Requirements are documented in Epics, User Stories and optionally Business (or Essential) Use cases.
Focuses on completeness of requirement and spends time in ensuring the requirement is unambiguous and has all the details.
Focuses on understanding the problem and being the domain expert so that s/he can answer questions from the development team swiftly and decisively.
Focuses on getting a ‘sign off’ on the requirements.
Focuses on ensuring the requirements meet the currentbusiness needs, even if it requires updating them.
Often there is a wall between the BA/Business and the Development team.
Agile BA (Often called as Product Owner) is part of the team.
Tends to dictate solutions.Has to remain in the problem domain, leaving the development team ‘space’ to explore different solutions.
Long turnaround. Quick turnaround.Focus on what the requirements document said. In other words, output (Artifact) is a well written thorough requirements document.
Focus on the functionality of the developed software. In other words, output (Artifact) is the software that meets thebusiness needs.
Understanding Business Value: Velocity is the total estimated cost (in effort or points) of the features that are 100% complete (i.e. signed off and delivered) in a Sprint or iteration. Each feature, or user story, listed on the Product Backlog has two Fibonacci scores. One for Size and one for Business Value. This is potentially a useful way to prioritize the Product Backlog, as a simple formula (value/size) can be used to order the backlog with the most important and valuable user stories first. The idea here is to put Fibonacci points for business value on every item (or User Story) on the Product Backlog, as well as the points for each feature’s size.
Traditional BA (Waterfall) Agile BARequirements are documented in Use Cases,Business Requirements, Functional requirements, UI Specifications, Business Rules.
Requirements are documented in Epics, User Stories and optionally Business (or Essential) Use cases.
Focuses on completeness of requirement and spends time in ensuring the requirement is unambiguous and has all the details.
Focuses on understanding the problem and being the domain expert so that s/he can answer questions from the development team swiftly and decisively.
Focuses on getting a ‘sign off’ on the requirements.
Focuses on ensuring the requirements meet the currentbusiness needs, even if it requires updating them.
Often there is a wall between the BA/Business and the Development team.
Agile BA (Often called as Product Owner) is part of the team.
Tends to dictate solutions.Has to remain in the problem domain, leaving the development team ‘space’ to explore different solutions.
Long turnaround. Quick turnaround.Focus on what the requirements document said. In other words, output (Artifact) is a well written thorough requirements document.
Focus on the functionality of the developed software. In other words, output (Artifact) is the software that meets thebusiness needs.
The development team provides the points for size, Whereas the business value points should come from the Product Owner/Business Owner.The key thing here is that the estimated business value is relative, i.e. a feature with a business value of 2 is twice as valuable as a feature worth 1; a 5 is worth 5 times a 1, etc.When you have Fibonacci points for size and for business value, you could do a calculation of business value divided by size to give the feature a priority score. It’s a simple way to sort the backlog so the high value/low effort features come out at the top.
Traditional BA (Waterfall) Agile BARequirements are documented in Use Cases,Business Requirements, Functional requirements, UI Specifications, Business Rules.
Requirements are documented in Epics, User Stories and optionally Business (or Essential) Use cases.
Focuses on completeness of requirement and spends time in ensuring the requirement is unambiguous and has all the details.
Focuses on understanding the problem and being the domain expert so that s/he can answer questions from the development team swiftly and decisively.
Focuses on getting a ‘sign off’ on the requirements.
Focuses on ensuring the requirements meet the currentbusiness needs, even if it requires updating them.
Often there is a wall between the BA/Business and the Development team.
Agile BA (Often called as Product Owner) is part of the team.
Tends to dictate solutions.Has to remain in the problem domain, leaving the development team ‘space’ to explore different solutions.
Long turnaround. Quick turnaround.Focus on what the requirements document said. In other words, output (Artifact) is a well written thorough requirements document.
Focus on the functionality of the developed software. In other words, output (Artifact) is the software that meets thebusiness needs.
You can also plot this on a scatter graph, which you can set up to put the high value/low effort features on the top right, and the high effort/low value features on the bottom left. But aside of prioritization, putting a business value in points against every item on the backlog allows you to calculate ‘Business Velocity‘, i.e. how much business value (in points) was delivered in each Sprint. You could plot this on a ‘burn-up chart’, showing the cumulative business value delivered over time – hopefully with an accelerating trend line.And you could use this graph to see whether the business value for each sprint is increasing or decreasing.
Traditional BA (Waterfall) Agile BARequirements are documented in Use Cases,Business Requirements, Functional requirements, UI Specifications, Business Rules.
Requirements are documented in Epics, User Stories and optionally Business (or Essential) Use cases.
Focuses on completeness of requirement and spends time in ensuring the requirement is unambiguous and has all the details.
Focuses on understanding the problem and being the domain expert so that s/he can answer questions from the development team swiftly and decisively.
Focuses on getting a ‘sign off’ on the requirements.
Focuses on ensuring the requirements meet the currentbusiness needs, even if it requires updating them.
Often there is a wall between the BA/Business and the Development team.
Agile BA (Often called as Product Owner) is part of the team.
Tends to dictate solutions.Has to remain in the problem domain, leaving the development team ‘space’ to explore different solutions.
Long turnaround. Quick turnaround.Focus on what the requirements document said. In other words, output (Artifact) is a well written thorough requirements document.
Focus on the functionality of the developed software. In other words, output (Artifact) is the software that meets thebusiness needs.
Complexity Points: This is used to measure the effort required to implement a story.During sprint planning on the basis of user story the development team and QA team states the complexity points using Fibonacci scores as explained above. Effort is defined on the basis of time required and also number of lines of code to be written by the developer’s and tester’s in order to execute the story. The user story that has High business value and low complexity point is addressed first.
