An area that has been gaining a lot of attention these couple of years is User Research which is an activity focused on generating insights for product owners and project managers into what drives adoption of a tool or feature.
For many of us that have seen Extreme Programming and lean methodologies, it is just another way of staying close to the user to find out what the underlying problem the user has. But for experts in the design and usability field it is one of the key aspect that drives their decisions in creating the experience behind a product. Therefore techniques such as Paper Prototyping have been adopted to create some minimum features that can be consumed and disposable in a very easy manner with very few resources consumed (mainly man hours from design and zero investment in development).
What makes User Research valuable for Scrum and agile teams is that for every release cycle if you incorporate some feedback from the core user, you have more possibilities for a successful feature or product launch. Since continuous releases is something that every software company is striving for, but getting it out the door is not the end result it is when the user interacts with the product or feature that determines the success of the launch.
Listening to user feedback.
In our team we experienced this lesson the hard way, we built a full blown product on time and the estimates planning with minimum fluctuations. But failed to understand which features had the most impact on the users and which ones that were chosen to be “killer features” the user did not care about.
We did our fair share of questioning users and experts in the field. But did not provide them with a “touch and feel” version of our features or product, so users imagined the desired product based on their experience and not the product vision developed by the team.
For another project which was an Atlassian Add-on focused on doing Agile Retrospectives inside a Confluence page, we talked to the users beforehand and then during each sprint we provided mockups using Invision that created clickable forms that the user could “click and react” that way we knew before coding what the user taught of the features in that release. Making it easy for us to adjust the features as the sprint started.
The team was able to understand what made an impact to the daily activities of the user regarding a team retrospective and for example we found out that some teams would like to have anonymous retrospective sessions for those teams that are new or that the members have not created thrust links within the team. We just released this feature this month in Agile Retrospectives for Confluence.
Where to incorporate user research.
Some housekeeping before we discuss how to incorporate User Research, the way we work is with a small development team consisting of 2 developers, 1 designer, 1 Product Owner and the Scrum Master. Scaling it will require some good coordination and thinking.
We use 1 and a half day of User Research sessions with 10 to 20 minute DEMOs to users and then 30 minute discussions with the interviewees. By the end of the day we present the findings to the team and discuss if we want to make improvements into the features for those important insights presented by the report from the User Research.
The important part is the discussion generated to make small improvements based on the research obtained by the team and to create deeper knowledge on the problem the user is facing and how the features or product will create value to their business process.
The process was applied to all of our products at SoftwareDevTools which is our project to build software products so scrum masters can do sprint planning, retrospectives and dailys inside Slack for agile distributed teams.
If you want to know more and how to adopt User Research into your Agile team, I suggest you check out this Webinar with Georgie Bottomley, Senior UX Research at Atlassian.
ccossio [at] nearsoft [dot] com
Products at SoftwareDevTools