Agile and user centred design working together
In my own experience and from reading various blogs, questions on the compatibility and possible conflicts between user centred design (UCD) and agile principles get raised. As an advocate of both sets of principles, I think they are compatible and can influence the likely success of a project.
Lets deal with the some of the questions.
There isn’t a clear role for designers in an agile process ?
In some agile literature, there can be a lot of focus on developers, scrum masters and testers etc. However, other roles such as designers and architects are considered important and included in the agile processes. The key distinction is that such roles may not be as full-time as developers etc, but that doesn’t mean they are not as important.
In a scrum process, there are two tasks prior to the start of a sprint, where I feel designers can and should contribute. The first, sizing stories on a product backlog, to help establish the ‘relative size’ of each user story. This sizing, as distinct from estimating, is based on the likely complexity, effort and doubt associated with completing the story. To that end, a designer can play an important role in the discussions on complexity, effort and helping to remove / clarify any doubt associated with any user interface related work.
The second, estimating stories and tasks as part of the sprint backlog planning. In this situation, the focus is on compiling an ‘ideal’ hours estimate for getting a series of tasks completed to finish a user story which is part of the backlog. As well as providing expert advice to help with the estimation, a designer may be committing to one or more tasks as well that relate to interface design.
User Centred Design is too strategic for agile ?
UCD can be strategic in terms of agreeing design principles and guidelines for a specific project and including user needs in the project vision through the use of personas. Such guidance is important in an agile driven project as in any other project management approach. In a scrum (agile) approach, I have used a release plan to good effect to identify at a high level, a road map of how the project/ product will take shape. A release plan illustrates over a number of sprints, the planned software releases and the features to be included in each sprint.
This release plan assists the scrum process and delivery team see the forest from the trees. To that end, design guidelines such as usability and accessibility principles along with the focus provided by personas, is important in identifying the sequence of work and the high level associated task detail. This information can be used during the preparation and sizing of the product backlog and where relevant with planning a sprint’s backlog.
Features can get rushed in agile and not meet user design standards ?
In any user story on a product backlog and before it is accepted into a sprint backlog, it must have a clear set of acceptance criteria (i.e. defintion of done). These criteria are set by the Product owner (i.e. business owner and in many ways a user representative). There is no reason that usability, accessibility and ‘local’ user criteria cannot be included, where relevant, into the definition of done for each user story.
If some of these criteria are not being adhered to during sign-off by the product owner, then the scrum master needs to address that issue promptly. This is a sign of agile principles not being followed properly, as opposed to a lack of fit between user centred design and agile.
If in the interests of getting a user story completed, some of the design criteria get dropped, then a ‘new’ user story should be added to the product backlog with these design criteria. The remaining acceptance criteria will be completed when that feature is included in a subsequent sprint.
To sum up, I hope that I have answered the above questions on compatibility between agile and user centred design. I have found that where there may be some ‘conflict’ between agile and user design, it is less to do with the two approaches and more to do with the business lowering the priority of design principles in the interests of getting the project/product completed relatively quickly.
Where there is any conflict, the use of a retrospective at the end of each sprint to allow the full team meet around the table and reflect on the successes and weaknesses of each sprint can resolve any such conflict.
Here are are some related links on the topic