COEPD – Center of Excellence for Professional Development Happy Learning
Acceptance criteria defines how a particular feature could be used from an end user’s perspective. It is a set of statements each with a clear understanding of the end outcome in terms of pass/fail which can be functional or non-functional requirements. It is also written to define the boundaries for a particular user story.
We must always write acceptance criteria from an end user’s perspective, so that it will be clear on what outcome or result a user is expecting on performing the action.
How to write Acceptance criteria?
While writing acceptance criteria one must keep 3 basic parameters in mind i.e. Role, Requirement and Reason with observable results. It should also include actors/actions/conditions/environment and a proper context.
How to write user stories with acceptance criteria?
<As a user> indicates the role
<I want to — > indicates the requirement
<So that I can — > indicates the reason
| User story pattern | Description |
| <As a user> | Indicates the role |
| <I want to — > | Indicates the requirement |
| <So that I can — > | Indicates the reason |
Let’s consider an example of a user story where a user wants the webpage search feature:
As a website user
I want to search on the webpage
So that I can find necessary information
Why do we write user stories with acceptance criteria?
As an organization while working for any project it is important to have everyone on same pace and must have updated knowledge on a product and its features. Writing user stories helps the team gain the shared understanding on a feature and also it helps the developers and testers to derive the test cases. And writing acceptance criteria helps to define the boundaries of a feature’s functionality and it defines the intent.
Business Value
BV is an important concept in Agile. It indicates User Story importance from the customer’s point of view. The top priorities User Stories should be implemented first in the development process. Business Value is how important is the feature for you as a business owner or a stakeholder from user’s perspective.
The advantage of assigning a quantitative business value allows us to subjectively track the amount of business value that your team is generating each iteration. Calculating business value and using that results to prioritize the Product Backlog is one of the most important things a Product Owner can do to drive profits and achieve a competitive advantage using Scrum.
This is estimated by Scrum Currency Notes. We provide Rs.1000, Rs.500, Rs.100, Rs.50, Rs.20 and Rs.10 Denominations. These estimations are done by the Stakeholders (Clients). If different values are selected by the stakeholders, then discussions will happen, and they agree to one BV value to that user story.
Complexity points
CP – Complexity Points CP is also known as Story Points (SP). CP is the effort required by the Scrum Developers to develop this feature (user story) using technology. Efforts include time taken to solve the complexity and write the code. CP is estimated by the Scrum Developers by using Poker cards. We provide pokers with values “?”, 1, 2, 3, 5, 8, 13, 20, 40, 100 and BIG. If the entire Project development takes 200 points, then this user story coding effort will be… how many points? … Thinking in this way, Scrum Developers will give CP to the User story. ). If different values are selected by the Scrum Developers, then discussions will happen, and they agree to one CP value to that user story.
Complexity = Amount of Work + Degree of Risk + Level of Uncertainty
