Agile Feedback on GUI and UX

Agile changed the way we develop and deliver versions. It also means there every two to three weeks developers will move forward and start working on something new. Receiving feedback as soon as possible has become more important. If a developer receives feedback on something he worked on two sprints ago, it will take him longer to resolve it (switching the development environment and getting the right source, think about the problem, fix it, time to build, test, check in and document the fix).

Of late, I have been talking a lot about the importance of feedback, especially related to the project you are working on. If you do not know what you are doing wrong, how can you fix it? (We all had this discussion at home). It also works the other way around, if you know what you are doing right you can make sure you do not stop doing it.

Agile changed the way we develop and deliver versions. It also means there every two to three weeks developers will move forward and start working on something new. Receiving feedback as soon as possible has become more important. If a developer receives feedback on something he worked on two sprints ago, it will take him longer to resolve it (switching the development environment and getting the right source, think about the problem, fix it, time to build, test, check in and document the fix). Preferably we would want to give that feedback during the sprint or immediately following the demo.

Even within 42, getting feedback on a project is sometimes difficult and we are always looking for a way to improve that. So we decided to run a trial with Atlassian’s Bonfire. Eventually, we would like to be at the point that we are using Bonfire to collect feedback on our projects right after each sprint demo. But first we start with a short trial!

Setup


Application

As a software company we are not short on projects which we could use for this test and, in all honesty, could really benefit from such a test. We decided to go with one of our internal projects called Goudvink. Goudvink is going to be our online tool for registering expenses and will be used by everyone in the company. For us this was a very good reason to get everybody’s feedback as soon in the process as possible.



As a part of the sprint demo, the application is compiled and deployed on one of our test servers. So we are going to do this test-session on a just demoed, deployed, close to trunk version of the app. Just the way it should be (wink)

People

At least once a quarter 42 organizes an event where the whole company will be present. Sometimes to exchange knowledge and update each other on their projects, sometimes just to socialize, in both cases there will be good food and drinks. Coincidentally, this event was last Wednesday. The idea is to have everybody test the app in about three minutes. Every issue they find, being usability, design, features, etc, will be registered using Bonfire.

Because we have the chance to end up with lots of issues, we also had to have a triage process in place. You probably do not want to confront the developers with the raw issues. First make sure that all the duplicates are removed. You might want to count the duplicates though, as they could provide some feedback on the priority. Also: do not remove the praises, they are just as important as the bugs. First of all, everybody likes to know they doing a great job and secondly, you do not want to lose a feature people like!

Bonfire

I mentioned Bonfire already a couple of times, let me explain! Bonfire is a great tool build by Atlassian is all about testing your web applications. Bonfire is a plug-in for JIRA and allows the user to quickly create issues and add annotated screenshots without leaving the context of the application their testing. This is great in normal day-to-day testing, but essential if you want to test an app in three minutes with 30 people. All the issues end up in JIRA, making it easy to triage, plan and track!


Results


A combination of food, drinks and agile testing sounds great, but reality is that it may not have been the best time and place to do this trial. On the other hand, it was a great informal way to teach people about feedback and how Bonfire could benefit in their project as well. The three minutes per person was a bit optimistic. I had to explain the app quickly, the purpose of this test and of course how to use Bonfire. We ended up with about eight people doing a test session and the total time spend was just over an hour.

There were about 20 issues raised during these sessions, some duplicates, some non-issues but most of them where really good issues and suggestions on improving the application. If you consider that it took about seven minutes per person that is a very good score. Even better is that eight people had a look add a new application, providing the team with feedback. The project got a bit more awareness within 42 and the team has a better feel for who its customers are.

Would we do such a session again? Absolutely! We will have to see how we organize it, but we will try to make it a standard process if possible. I also hope that my Bonfire pitch to the other developers pays off, I genuinely think it adds value to for an organization and it will pay itself back with less time spend on testing but getting better (and quicker) feedback.