|
|
Breaking down by acceptance criteria: test scenarios / test case
This strategy is useful when it is hard to break down large PBI’s based on functionality alone. In that case, it helps to ask how a piece of functionality is going to be tested. Which scenarios have to be checked in order to know if the functionality works? Take a task planning system:
As manager I can assign tasks to employees, so they can work on tasks
If we consider this functionality based on potential scenarios, we can break down the item into:
- Test case 1: If an employee is already assigned, he or she cannot be assigned to another task;
- Test case 2: If an employee has reported in sick, he or she should be visually marked;
- Test case 3: If an employee has reported in sick, he or she cannot be assigned to a task;
- Test case 4: If an employee is not yet assigned, they can be assigned to a task;
- Test case 5: Employees can be assigned with a touchscreen monitor;
Sometimes, test scenarios can be very complicated because of the work involved to set up the tests and work through them. If a test scenario is not very common to begin with or does not present a high enough risk, a Product Owner can decide to skip the functionality for the time being and focus on test scenarios that deliver more value. In other cases, test scenarios can be simplified to cover the most urgent issues. Either way, relevant test scenarios can be easily translated into backlog items and added to the sprint or the backlog.
|
|
|
|
|
Breaking down by acceptance criteria
The “T” in Bill Wake’s INVEST acronym stands for Testable. How will we know the user story is complete? Many teams, when they have this discussion, choose to document the answer to that question as Acceptance Criteria (also know as Acceptance Tests or Conditions of Satisfaction). Let’s look at a sample User Story and the Acceptance Criteria their team agreed on:
Example Story: As a non-english speaking user, I want the system to read my locale preferences from my profile and display the appropriately localized version of the website, so that I can read it without having to manually choose each time.
Hopefully you’ve noticed that this user story contains vague terms as well as a conjunction – our first two split opportunities. Let’s ignore those for now and just look at the acceptance criteria that the team building this story came up with:
- The system will support all Locale Policies defined in the API
- The system will use a URL switch to indicate the Locale Policy
- The user will see the correct language without manually refreshing the system
Notice that each of these criteria could become its own vertical slice, or in some cases multiple slices. For example the first Acceptance Criteria could be split into two or three slices:
- Support Japanese Locale Policy
- Support the most common Locale Policies for our site: English, French, German, Japanese.
- Support all specified Locale Policies
The second Acceptance Criteria could be broken down as:
- Don’t fail when a URL contains a Locale Policy (in other words, don’t localize but don’t give a Not Found error either).
- When a URL contains a Locale Policy, pop up a page that indicates “we noticed you want to display the page for “Language”, is that correct? (validation step)
- When the URL contains a Locale Policy, display the page for that policy.
The third step could be broken down as well – make the refresh manual as an interim step, then make it automatic.
|
|
Breaking down by acceptance criteria: browser compatibility
Modern browsers tend to be more compliant to standards, and easier to develop for, while older browsers often require hacks and customizations to get everything to work properly. Take this story:
As customer I can view product details, so I know if I want to buy it
By considering the browser versions, we can break down the work into smaller items:
- As customer I can view product details in a standards-compliant, modern browser, so I know if I want to buy it;
- As customer I can view product details in IE7, so I know if I want to buy it;
- As customer I can view product details in a text-browser, so I know if I want to buy it;
Although it would certainly be preferable to deliver this functionality with full support for all browser-versions, there are certainly scenarios where this break-down is feasible. Perhaps the vast majority of the visitors use modern browsers, requiring less effort to support old browsers (other than a warning). Or maybe the application is run on an internal network where all users use Internet Explorer 7. Again, this allows the Product Owner to prioritize, and helps to team to spend time and effort on the most important functionality first.
|
|
Breaking down by acceptance criteria: input options / platform
Most web applications have to support various input options and/or platforms, like desktops, tablets, mobile phones or touchscreens. It may be beneficial to break down large items by their input options. Take a digital Scrum Board for a team:
As team member I can view the Scrum Board, so I know how we’re doing as a team
We can identify the following input options:
- As team member I can view the Scrum Board on my desktop, so I know the status of the sprint;
- As team member I can view the Scrum Board on my mobile phone, so I know the status of the sprint;
- As team member I can view the Scrum Board on a touchscreen, so I know the status of the sprint;
- As team member I can view the Scrum Board on a print-out, so I know the status of the sprint;
By breaking down large items this way, the Product Owner can more easily prioritize which input options or platforms are more important. A desktop-version is likely to be sufficient for now, while a mobile version can be pushed to a future sprint. Or perhaps the print-out can be implemented with a simple PDF capture for the time being, without having to create a version specifically suited for print.
|
|