gile software development has hit the mainstream! Since the Agile Manifesto was published, various software development methodologies that follow the manifesto’s values have steadily gained popularity. Many organizations are adopting these lightweight processes to get their software built.
Many of the Agile methodologies recognize and value the input of users as domain experts:
- Extreme Programming requires that a customer/expert user be part of the team on a day-to-day basis.
- Crystal Clear requires the software to be put in front of users at least twice to gather feedback before the software can be released.
- Scrum expects regular demonstrations of the product, albeit to stakeholders, at the end of every sprint.
These are all good suggestions that will help create more useful and usable software. However, consider the very real possibility that no users will be available to sit with the team day to day, or an available user is not representative of the majority of the user base. It is not sufficient just to say that a user should be part of the team. Development teams need ways to extract the right information from their users, to verify assumptions, and to validate design decisions.
Fortunately, another emerging methodology, User-Centered Design (UCD), focuses entirely on designing to meet the goals of real users. If Agile software development is about building the thing right, then UCD is about building the right thing. Understanding the needs and goals of the users is incredibly important to the success of software projects. It is certainly as important as other issues that receive a lot more attention, such as delivering on time and the maintainability of a system. Who wants to build software that is not going to be used or makes it harder for users to do their jobs? And how long will users accept clunky, difficult-to-use software? Projects often need to be re-implemented due to an unmaintainable code base or a legacy technology. If you are building software in a competitive market, the issue of software usability can mean the difference between a profitable company and going bust.
This article explains how to integrate Scrum with UCD, as Scrum recently has become the most popular Agile methodology. However, because Agile methodologies have very similar properties (frequent and early delivery, valuing working software over design documentation, responding to change, and so on), you can apply the principles and benefits discussed here to integrate UCD with any of the other Agile methodologies.
Scrum and Product Increments
Scrum is a lightweight process for software development projects, based on a few core principles. It is not a rigorous process that should be followed to the letter, but is rather a framework to give a team the tools they need to communicate and adapt the way they work depending on their environment.
 |
|
| Figure 1. Scrum Process Diagram: A backlog of features is fed into each sprint at the beginning. Each sprint produces a new functional increment to the product. |
The Scrum process has the following core characteristics (see Figure 1):
- Product backlog: A prioritized list of features for the project.
- Sprint: A regular period of time in which the team commits to deliver one or more items from the backlog. When the work for the sprint is set, it cannot be changed without aborting the sprint. The result of a sprint must be a fully functional and potentially releasable increment of the software.
- Sprint kickoff meeting: A planning meeting at the beginning of the sprint where the team members estimate which features from the backlog they think they can commit to delivering within the sprint.
- Daily standup: A short meeting held once a day that provides an opportunity for every member of the team to report on progress made the previous day, raise any issues, and make people aware of what they are planning to work on the following day.
- Sprint burndown chart: A big, prominently displayed chart that shows the progress of the team against the work remaining for the rest of the sprint.
- Sprint demo: A demonstration to the project sponsors at the end of the sprint showcasing the work that has been completed within the sprint.
- Sprint retrospective: A short meeting for the team to review their working practices over the last sprint and identify areas to change in their day to day process.
A Scrum team is made up of the following core roles:
- Product owner: The person who makes the decisions about which new features are planned for the product, and in which sprint these features are implemented.
- Scrum master: The person who helps the team get the work done. The Scrum master’s primary responsibility is to remove any obstacles that may stop the team from meeting their commitments.
- Self-organizing team: The group of people who are responsible for estimating and implementing the features requested by the product owner.
The power of Scrum is its simplicity and rigor. The team performs a contiguous number of sprints. The output of each of these sprints is a visible product increment (i.e., new features that can be demonstrated and potentially released to the users). This gives the team a regular sense of achievement and makes the progress of the team very visible to the rest of the organization. With Scrum, there is nowhere to hide!
Enter User-Centered Design
UCD is a philosophy for designing anything: a software application, a kitchen, a mobile phone. It is an iterative process that focuses on the goals of the end user. Design decisions are grounded in an understanding of user goals together with context of use. This understanding is achieved through user research. UCD also seeks to validate and improve on decisions through user testing. The basic process for UCD, as laid out in the standard ISO13407, is:
- Identify the need for human-centered design.
- Understand the business and organizational goals and requirements.
- Understand the end users, their goals, and the context in which the system will be used.
- Produce design solutions based on this understanding.
- Evaluate/validate designs (primarily through user testing).
- Repeat, iteratively, until the system satisfies the understood user and organizational requirements.
Figure 2 shows a UCD process diagram.
 |
|
| Figure 2. UCD Process Diagram: UCD is an iterative design process that verifies design decisions, primarily through user testing. |
The problem with UCD in software development is that the ‘design’ element is usually taken at face value. Many people believe it must be complete before the implementation of software has started. This means completing a number of iterations of the design and verification before the design is ready to be implemented. That approach suffers from the same fundamental flaw as performing all the technical design upfront: The design is not proven until it is actually implemented and tested in context. Performing usability testing with the real system at the end of a long waterfall implementation is often going to be of limited use, as the project likely will have very little scope for change at that point.
With Agile methods, the approach can be different as there is implicit recognition that software is soft! Development teams can change it and modify the design at any point. The implementation of software is really just the next iteration of the design – the next level of fidelity.
UCD in an Agile Environment
Agile projects do not suffer from stringent change control. They embrace change. In fact, two of the core values of the Agile Manifesto (responding to change over following a plan and customer collaboration over contract negotiation) allow development teams to respond to new findings from user research/testing and to deepen their understanding of users while implementing software.
The core structure of a Scrum project provides some natural integration points for the activities required for UCD.
Pre-Sprint Iteration of Design
The tools and techniques that have been developed for lightweight iteration of an initial design in Scrum, such as paper-prototyping for design and prototype walkthroughs for verification, are still entirely valid for UCD. They also provide a good fit when working with a product owner to clarify the features in the backlog for impending sprints.
Regular Feedback from Users
Scrum requires each sprint to produce a fully functional and potentially releasable increment of the software. In the book Agile Software Development with Scrum, Ken Schwaber and Mike Beedle recommend thirty days for a sprint, but many teams work on two-week sprints. Having a fully functional piece of software every two weeks?that can be used for usability testing?is incredibly powerful. The design can be verified against real users at regular intervals, allowing the results to feed back into the backlog as work for future sprints.
Improved Collaboration
Due to the dynamic nature of Agile projects, all activities must be performed many times over, in small steps. An Agile team defines a small section of the requirements, verifies and designs these requirements, implements the resulting features, tests the implementation, and then begins again.
For this approach to work, members of the team from all disciplines must remain committed to the project for its duration. A feeling of collective responsibility emerges as designers, developers, and testers work together daily. This is in stark contrast to the more traditional approach, where people from each discipline perform their work at separate times, each passing some static deliverable on to the next group.
Elusive Context
Creating software that allows users to achieve their goals in a seamless manner requires teams to verify the intended solution continuously. As the team moves through the backlog of features (or user stories), it fleshes out and designs each one, as prioritized by the product owner. However, the team must also consider the solution’s context of use every step of the way.
When creating a design upfront, retaining the context is not such a difficult prospect in the short term: When the user story is initially created and added to the backlog, the context may be obvious. However, when it is picked up again for design or implementation, the context may not be so clear. In fact, a common complaint of user-experience professionals starting out in an Agile environment is that the backlog is made up of a disparate set of features with no contextual information. Retaining the context of use in an Agile environment is critical to ensuring a holistic rather than a fragmented and disjoined approach to the solution.
The ultimate aim is to create a seamless user experience, providing a natural, unified flow that helps users achieve their goals.
| Editor’s Note: A follow-up DevX article will show how important the context of use can be when implementing user stories, and it will introduce some techniques from UCD to help retain context across stories. |
Planning for Iteration
By integrating UCD techniques into Agile projects, project teams attain the tools to gain a deeper understanding of their users and elicit invaluable feedback about early design decisions. Frequent delivery?a common property of Agile projects?provides the perfect opportunity to receive feedback against the latest level of design fidelity: working software. Teams must recognize the importance of this feedback and make time to react to the insights discovered through user testing.
 |
|
| Figure 3. Release-Level Scrum Burndown: The team commits to delivering the first version of the new product in nine sprints. |
A Real-World Example
Consider the following scenario. The marketing department has identified a gap in the market that a new software product could fill. After some high-level estimates, the team decides they can deliver the first version of the software to market in nine sprints. The team draws up a release-level burndown that looks something like Figure 3.
Everything is going great for the first few sprints. The team is steadily adding new features to the product, and each demonstration is a success. After three sprints, enough of the product is in place to allow some of the user scenarios to be tested. The user testing proceeds and the results are mostly positive, but some discovered issues need to be fixed. One area in particular was difficult for the users to understand, so the team needs to iterate over the solution. Unfortunately, new stories need to be added to the backlog to make these changes. The adjusted release burndown now looks like Figure 4.
 |
|
| Figure 4. Result of Rework from First User Test: Rework of the existing software is required after user testing uncovers usability issues. |
The good news is that the team has gathered some early feedback to fix problems in the user interface early. This information can also be used to improve the rest of the design. The bad news is that after only three sprints the product owner has some difficult choices to make:
- Push out the release date?
- Drop some features?
- Risk the uptake of the product and leave the usability issues in place?
This is not a one-off situation, either. There are more user tests planned in another three sprints. More issues almost certainly will be uncovered, as the product will include a new set of features. The work required to fix the next set of usability issues pushes the plan out further (see Figure 5).
 |
|
| Figure 5. Result of Rework from Second User Test: New features are added to the software, and there is more rework to be scheduled, potentially pushing the delivery date back further. |
As these complications illustrate, shortening the feedback loop between the product development team and the users provides the opportunity to improve the usability of software, but it does not come for free. However, responding to the findings of user testing can mean the difference between an intuitive and usable product and a development team bogged down under a barrage of “maintenance” support calls from users.
Make the Most of User Feedback
Not only must teams who use UCD techniques in Agile projects plan to incrementally implement new features, they must also plan to iteratively improve the design and usability of their software as the understanding of their users deepens. Yes, product owners must make difficult choices when issues arise. But if a team plans to perform usability testing frequently, it must also plan to react to the information the testing provides.
By recognizing that each round of user testing will produce a certain amount of rework, teams can budget for it upfront. By making the case for iteratively reworking the software explicit through planning, the team can set more realistic expectations for product owners.
