Patterns for breaking down usability and UX re-work

So you’ve just finished usability testing in your Sprint and have a pile of changes for  your agile team to implement. Some are changes needed will probably mean the team needs to adapt its Definition of Done to ensure that they create a higher level of quality. Putting in usability criteria into the Definition of Done isn’t as rare as you might think it is. Other changes will now require new Product Backlog items to be written. When you go into Backlog Refinement, the estimates come out to be larger than a single Sprints worth of work. How do you break down the UX changes that are needed into smaller, bite-sized User Stories?

This was one problem I faced not too long ago. After doing some usability testing, there was a significant body of work to do. While many of the estimates for the work were very high, the effort (to use Mike Cohn’s analogy) was more like licking 1,000 stamps than brain surgery. So here are the top patterns I used with the team to break down the work.

1. Text changes first

Labels, nonclementure, and formatting were the easiest change to make, particularly where visual flow and visual contrast were concerned, so where stories required these surface UI changes, these were done first.

2. By most frequently used

In many instances, the usability recommendations encompassed many, many, many pages. One of the easiest methods we employed to break down work estimates was to list the pages affected and then order the pages by their frequency of use. Pages were then grouped into three categories — top 20%, next 20%, bottom, 60%. The group that had the highest traffic received attention first.  For the most part, those pages that fell into the bottom 60% were not changed.

3. By highest value

While there was agreement that addressing the usability issues on most frequently used pages was of high value, the team also recognised that some pages were not used often, but represented a very significant step in a process that was critical to get right. The likelihood of human error in these pages from a risk perspective was also taken into consideration. These high-value pages were identified by business and ranked in much the same way that they helped the Product Owner in the past rank functionality. In many cases, these were pages that were of high cognitive complexity — many fields and a lot of text to be entered. Again, these were grouped into 20%/20%/60% split and the top 20 ranked higher in the Product Backlog to address than the remaining 20/60.

4. By supported area

One of the areas of concern by the Team was in making changes to areas within the software solution — Microsoft Dynamics CRM — that were not supported by Microsoft. If the Team made a change, and the software was upgraded and ran into problems, the Team doing the maintenance would be left on their own. So, we made a choice to split some of the User Stories by “supported area”, with changes required to supported areas, e.g. the body of a page, ranked higher than those that were not supported, e.g. the left-hand side navigation menu.

5. Illogical to the logical

Where workflow was involved, the steps were broken and ranked to identify the pages that represented the most confusing interaction design to the least confusing. The time taken on pages during the usability testing was one factor that contributed toward it being identified as ‘more confusing’ as did the visual complexity of the page.

6. By most valued user

One of my favourite patterns is to break up stories so they deliver the most value possible to one user before delivering value to another one. This is a pattern we also adopted for breaking down large usability stories through ranking the user types, and then identifying the pages they used within the application. These pages were identified for usability improvements prior to other pages used by other users.


Adding someone with UX skills into the Development Team is an important step to ensuring that the team’s product Increments are both usable and accessible. Slicing updates and changes to a product’s user experience isn’t difficult though. With a few simple patterns added to the team’s standard ways of slicing stories into thin, vertical slices, will continue to ensure value is delivered to end users.


About the author

Related Posts

Groupthink: the bane of high performing Agile Teams

What makes an agile team great and why? After coaching a number of teams in Scrum, we’ve now seen a number that, after a some months now, could be considered high performers. Some of these go bad and reject any external criticism regardless of how accurate that might be. Why do these teams go bad? Groupthink might have the answer.

agile iq academy logo 2022-05-05 sm

Enter your details

search previous next tag category expand menu location phone mail time cart zoom edit close