Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Agile and UCD: Building the Right Thing, the Right Way : Page 3

When integrated, Agile software development and User-Centered Design (UCD) allow development teams to extract the right information from their users, to verify assumptions, and to validate design decisions.


advertisement

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.



Jon Dickinson is the principal consultant at Accolade Consulting. He focuses on helping organizations improve the software they deliver through agile development techniques.
Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap