Scrum is focused on the planning and following-up parts of a project. Three roles are specified for Scrum: The Product Owner, the Scrum Master and the Team. The Product Owner is the voice of the customer, this person (or team) has the domain knowledge and the mandate to decide what will be built. The Product Owner is in charge of the Product Backlog, which contains both the plan and the requirements (features to be built, etc.) for the project. The Scrum Master is in charge of making sure that the team follows the Scrum rules and stays agile. This person is an ordinary team member but has great process knowledge and acts as a coach. The Team is a cross-functional group of people tasked with implementing the requirements.
Each iteration in Scrum is called a Sprint, and this sprint usually lasts between 3 and 5 weeks. In the beginning of each sprint there is a Sprint Planning meeting, where the Product Owner presents a chunk of the Product Backlog that he or she would like to see built at the end of the sprint. The team estimates the chunk according to their knowledge and skill, and makes sure it will fit during the sprint. Once the team and the Product Owner have agreed that they have a well-sized and meaningful chunk of features to build, which is called the Sprint Backlog, the team builds it (supported by the Product Owner for requirement details). Each day during the sprint, a very short project status meeting occurs. This is called the Daily Scrum. During this meeting, each team member answers the questions: What did you do yesterday? What will you do today? What might hinder you from doing that today? The reason is to keep everybody up to speed and solve difficult problems as soon as they arise. At the end of the sprint there is a Sprint Review meeting, where the team shows their built chunk and the Product Owner gives feedback. This feedback might then be a part of the Product Backlog and put in the Sprint Backlog for later sprints. After the Sprint Review, there is a Sprint Retrospective meeting where the sprint is analysed and the team can adjust/improve/correct their process before the next sprint starts.
The team sprints until the Product Owner is either content or out of money. This requires each sprint chunk to be a potentially shippable product. To make this work there has to be some kind of rough plan as to what will (or might) be released to the Product Owner in each sprint. Hence, the team usually starts by building a foundation (as well as getting the process on track). This sprint is called sprint zero.
As with all agile methods, you are supposed to add to the method what you think is missing. This is why you often see Scrum combined with Extreme Programming in software development, but Scrum in itself has many other application areas. The following is what a combination between Scrum and user experience would look like.
UX Sprint Zero
For the user experience practitioner, the sprint zero should answer why the project shall be built (usability goals and effects) and who it will be built for (target groups, the customer, other stakeholders). This is well-taken care of using Effect Management in Scrum. Sprint zero should also contain some basic design, to get a good start in the following sprint. This design should be lightweight. This sprint zero is counted in weeks, not months. In a single week of collaborative design, one should be able to sufficiently understand the project objectives and the high level functional scope so that the the size of the project can be roughly estimated and a sprint release strategy can be formulated. It is the same here as in pair programming, two heads think better than one, and you will get automatic quality control of your ideas. You should end up with a rough overall design for the project. Since Scrum is running in iterations, this design will have to be split up in parts that can be designed, built and validated somewhat independently.
If the project is large, break it down and do parts in different agile teams. It is still possible to have only one or two UX practitioners, even if you have two or three teams.
UX Sprint Planning
Since the UX practitioner is tasked with creating usability goals for the project, this also applies to the sprint. This is done together with the Product Owner, who should create a general sprint goal for the sprint. The usability goals will help the team in estimating how long it will take to build each feature.
Creating low fidelity prototypes (mockups) which easily may be brought to a tester, stakeholder or user for informal usability tests gives optimal feedback given the time invested.
If such mockups of the design exist, it will greatly aid the team's estimation task, since a visual explanation helps understanding than the more formal requirement from the backlog. Also, alternative solutions can easily be discussed and dealt with swiftly using prototypes.
UX Sprint Running
For each sprint, it is not necessary (nor is there time) to create more than the before-mentioned prototype, since there is time set aside during the sprint for communicating details. But exactly how this takes place can be discussed. Here are two suggestions how to handle the communication between UX practitioners and developers during the sprint
- Plan ahead
Here, the design and the development are seen as two parallel tracks. The developers run their course as before, and for them to be able to do this, there must be enough designed of the user interface before the start of the sprint where the feature is to be built. This demands that the sprint zero is somewhat deeper than mentioned above or that the first sprint for the developers mainly consists of non-GUI features. In reality, both of these statements are required, since UX design penetrates further down than just the user interface.
Additionally, as shown in the figure, the UX practitioners are one or two steps ahead all the time in this method. While the developers implement design, the features from the last sprint are being usability tested, and at the same time, the research and design for the following sprints are done. The advantage of this approach is the added time for research and design compared to the following suggestion, and this is the reason this might work better for some people.
- Incorporate design sessions
And for other people, this approach might be more suitable. In this approach, the detailed design is done in cross-functional design sessions during the sprint. This gives time in sprint zero for deeper research (such as a better detailed sprint release strategy) that pays off later as well as time during the sprint for basic design for later sprints. When a UX practitioner is a team member, this basic design time will be accounted for during the sprint planning.
The design sessions themselves work as following: A session is the start of the building of a feature. It requires the whole team including the Product Owner and UX practitioner (as well as at least a tester), to give everyone in the team an understanding of the design and an appreciation for the process and tradeoffs necessary for a good design. The group designs the GUI together, in as much detail as possible. The rest of the details follow generic platform guidelines, i.e. do not dwell on pixel-specific issues unless they really make an impact on the user experience. The design session is timeboxed (depending on the size of the feature), from 30 minutes to about 4 hours. For a well-defined increment of the product, i.e. a good sprint backlog, it is possible to do a longer design session for all of the GUI design of the features at the start of the sprint.
This last suggestion is advantageous since it gives more time for usability testing and quality assurance during the sprint. This testing can be done when a feature (or a set of features) is finished, but the recommendation is to do it the last week of the sprint. Then you test all the features that have been built so far with select users. In parallel you may run an informal pre-validation test (depending on how many testers and user representatives that are available) since this gives a lot of good input to both usability QA and to the product owner before the sprint review meeting.
Apart from all of the above, do not forget to try adding what works for you today.