Ten ways to improve the usability of products that Agile teams build

Software development that uses a waterfall method is likely to deliver the wrong thing, too late. The intent of the Agile method is to deliver working software sooner, so the intended users—our clients and their customers—can provide feedback that steers us to deliver the right thing.

There’s a tension between delivering on time and delivering the right thing. In fact, the rush for on-time delivery can result in the wrong thing—an unusable product. There are ways to prevent this. User research can help.

The goal: deliver valuable software

When squeezed by deadlines, Agile teams may sacrifice time to make the product more usable, despite the first of the Agile Manifesto’s principles:

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Valuable software is usable software. As an aside, valuable software has other attributes, too, but this discussion focuses on the usability of products that Agile teams build.

Data about what’s usable generally comes from testing with users. Much of that testing can’t take place until after each piece, parcelled into Agile stories, is done. Development teams—consisting of analysts, developers, quality-assurance testers, usability researchers, interface designers and comtent designers—may consider an Agile story to be completed despite the lack of feedback from the intended customers about its usability (and other measures of value).

Ways to build usability into your Agile process

It’s possible to balance the tension between building the right product and delivering a product on time. Here are some ideas—some of which might seem radical.

• Use reporting tools that can track additional work caused by usability defects, so that such work can be factored into the projected release date. For example, this burn-down chart tracks two types of story points, or development work. After each sprint or iteration, the blue bar shows the remaining story points. In addition, as user feedback and testing reveals unexpected high-priority defects, the orange bars show the accumulating story points to fix those defects. The release date of a usable product is where the two projected lines cross:
  

• Reduce the likelihood of major changes in the mental model, the workflow design, and the interaction design. Ensure the designers understand the entire set of features in sprint zero—before development begins. Consider possible design solutions for key workflows, then share this vision with the whole development team, and test it with customers. To finish this work faster, involve developers and QA in the design process. (The Five Sketches™ method is one highly efficient way to do that.) A shared understanding of what customers or users need, including their recurring problems, attitudes, behaviours, knowledge and usage environment—the outcome of formative research done at the project’s discovery phase—helps eliminate the need for major changes.

• Test the usability before developers write any code. While testing the finished product helps assess its usability and hence its value, it’s also possible to test beforehand, using paper prototypes or interactive mock-ups or prototypes.

• Allow Agile stories that deliver a quick, “working” prototype, and see prototypes as equal to a “working” piece of code. This enables formative testing on paper prototypes or interactive prototypes before developers write code. The Agile principle that demands working software from every iteration allows some wiggle room: “Working software is the primary measure of progress” but not the only measure. This means the team members—all team members on an Agile team, including developers, QA, UI designers, and UX researchers—can focus on design, prototyping, and validation together instead of making a designer or usability work one sprint ahead or one sprint behind the rest of the team.

• Put substantial usability deliverables in their own stories, rather than in the acceptance criteria of stories that build functions. Especially when you need work done that substantially shapes the user experience but that is not related to a specific feature, regard this user-experience work just as you regard database-, architectural-, or other foundational work.

• Include bits of usability work in an Agile story now, if it will reduce future usability defects. Sometimes the Agile principle of simplicity—which pushes us to maximize the amount of work not done in any given story—must be balanced with the Agile principle of technical excellence—which posits that good design enhances agility. In other words, deliver something a little less simple for individual stories that, collectively, will avoid an additional story to clean up a predictable usability deficiency.

• Understand that unusable software is broken. There’s no value in meeting a delivery date with something that people cannot use. Better to deliver fewer functions that work well. Don’t be afraid to deliver less. As long as a software release provides meaningful use, it has value.

• If management likes waterfall release planning, add placeholder stories for usability fixes. If you’re not fully Agile, don’t set yourself up to cut usability fixes that were unknown at the start of the release cycle. At the start of the project, pad the backlog to allow for unknown but expected usability-defect fixes. That way, usability won’t be seen to cause delays to the release date.

• Embed usability the story-review and sign-off processes. Before work on a story can start, it is usually reviewed in a ten-minute discussion by a small group that represents the team’s skillsets:  a developer or perhaps a dev-ops, a quality assurance practitioner, a business analyst, and perhaps a content strategist. Include the usability analyst in that meeting, to point out usability standards and to offer design alternatives for consideration. Similarly, when it’s time to agree that the story is finished, include a usability analyst to identify any no-go usability problems, as well as any potential problems to test sooner with users.

• Look for systemic problems, especially if the team generates many usability defects. Remember the last principle in the Agile Manifesto: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.” Your team may need to modify its process.
  

Balancing Agile principles

The above tips are in line with the Agile Manifesto—when its principles are well balanced. It’s easy for a team to excel at some of the principles, and forget the others. For example, development teams focus on speed, citing these two principles:

• Short sprints. Deliver working software frequently [in short sprints that last] … a couple of weeks ….
• Working software. The primary measure of progress is working software.

Let’s look at each of these principles in more detail.

Short sprints enable feedback

Short sprints provide feedback sooner. For example, management gets frequent data with which to predict when the software will be built and ready for release. This simplified burn-down chart shows one approach:

Short sprints also allow teams to get customer feedback sooner, so the team finds out sooner if they’re building the wrong thing. In fact, the Agile Manifesto assumes that some of the feedback will result in changes, hence this principle:

• Expect change. Welcome changing requirements, even in later sprints or iterations. Agile processes harness change for the customer’s competitive advantage.

For management, re-opening a previously completed Agile story in response to a usability defect makes its projections uncertain. Fortunately, it’s possible to adapt the reporting tools to allow for defects and feedback. The modified burn-down chart, above, shows one approach.

Working (prototyped) software enables feedback

The Agile Manifesto declares that working software is the primary measure of progress, but it’s not the only measure. Another measure of progress is feedback—such as usability research that provides quantitative performance data and qualitative observations and ratings of customer experience.

Summative testing of an as-built feature occurs after developers write the code for the feature. This testing results in the usability defects shown in orange, on the above burn-down chart.

Formative testing of an unbuilt feature occurs before developers write code the feature. This testing is often done with prototypes, especially when the team wants to test an interaction design, a workflow, or even the mental model. Developers may need to help build a testable, working prototype.