What does an “improvement” look like?
In Continuous Improvement, requests in your backlog are delivered as improvements. This guide walks through two typical improvements, then shows how a larger request is broken into several.
The short answer
An improvement is a single screen, or a single capability, that does one job for its users. It is described by a small set of use cases, usually less than 10, and it is built, reviewed, tested, and released as one unit.
A one-sentence description of something a person needs to do, written from their point of view: “As a user, I want to…, so I can….” Use cases set the scope of an improvement and become the checklist it is tested against.
Example: a report
A common first improvement is a report: a list of records the team works from every day, with filters, search, and sorting. Figure 1 shows the screen. The six use cases below it define what the screen must do. Hover or tap a use case to see which part of the screen it covers.
Use cases for this improvement
- 1ViewAs a user, I want to view all open orders in one list, so I can see the current workload.
- 2FilterAs a user, I want to filter the list by status, owner, and date range, so I can focus on the orders that matter to me.
- 3SearchAs a user, I want to search by order number or customer name, so I can find a specific order quickly.
- 4SortAs a user, I want to sort by any column, so I can see the newest, largest, or oldest orders first.
- 5PageAs a user, I want to page through long results, so the report stays fast as the number of orders grows.
- 6ExportAs a user, I want to export the filtered results to CSV, so I can share them or work with them in a spreadsheet.
Clicking an order to see its full details is not part of this improvement. That is a separate screen, covered next.
Example: a details page
Opening an order from the report to view and edit it is a second improvement. It is another screen with a different job, so it gets its own set of use cases.
Use cases for this improvement
- 1OpenAs a user, I want to open an order from the report, so I can see everything about it on one screen.
- 2DetailsAs a user, I want to see the customer, owner, dates, and totals together, so I don’t have to look them up elsewhere.
- 3Line itemsAs a user, I want to see the order’s line items and amounts, so I can confirm what was ordered.
- 4EditAs a user, I want to edit the owner, status, and due date, with required fields checked before saving, so the record stays accurate.
- 5HistoryAs a user, I want to see who changed what and when, so I can follow the order’s history.
- 6ReturnAs a user, I want to return to the report with my filters and search kept, so I can pick up where I left off.
Larger requests: a basic CRM
A request for a whole system is split into several improvements before work starts. A basic CRM, for example, is about five. Each is scoped, built, tested, and released on its own, so the team can start using the first while the next is in progress.
Table 1 — Basic CRM: 5 improvements, about 27 use cases
How requests are split
When a request is larger than one improvement, we split it before work starts and agree the order with you. These are the most common cases.
- Several screens with different jobs
- One improvement per screen. A report and the page behind it are two improvements, as in sections 2 and 3.
- A new integration and the screens that use it
- Connecting to an outside system is usually its own improvement, followed by the screens or workflows built on it.
- A whole system or module
- A request like “build us a CRM” becomes a sequence of improvements, as in section 4.