AuraQ has vast experience helping organisations find the gaps that can be filled to enhance their business. This could be to improve efficiency, integrate legacy systems or deliver new portals and strategic applications to create competitive advantage. Contact us to request a free, no obligation Gap Analysis.
13th Apr 2018
Handling feedback in agile development
Agile development is a methodology which favours short development sprints, with each sprint ending in a release containing new features and fixes. Each development sprint is made up of stories which can vary in size and complexity from the large (as a manager, I would like users to be able to create expense claims so that I can handle their payment within the app) to the small (as a user, I would like the homepage text to show a title so I know which page I’m on). The details of Agile development have been covered elsewhere in this blog, so in this particular entry we’ll be looking at how to handle and create meaningful feedback and how to turn that feedback into stories for future sprints.
Mendix
Figure 1: Mendix application feedback form.
The Mendix development platform has built-in tools for handling feedback and as a Mendix-partner company this is what my blog will focus on. However, the approaches laid out here can apply to other development platforms even if the terminology isn’t exactly the same. A major advantage when creating feedback in Mendix apps is that a feedback button can be added to page layouts so it appears throughout your app.
Clicking the feedback button allows the user to raise a feedback directly from the app. As shown in figure 1 this page requires the user’s name, email address and a subject. There is also the possibility of providing Additional Information, a relevant file and an automated snapshot of the page. When this feedback is created it will show the developer what page the user was on when they raised it. If the feedback eventually becomes a story then there will be a link to the page within the Mendix Modeler during development which will take the developer directly to that page for ease of debugging. The screenshot and page logging automates two of the most important factors in debugging an issue; where it happened and what that looked like. However, making sure that the subject and description clearly define what the issue is will go a long way towards getting your feedback handled in a timely manner.
Any feedback raised through the application will be added to the “Feedback” section of the app in Sprintr. Sprintr is Mendix’s built-in application management platform, which encompasses many different features. The features include, but are not limited to, sprint and story management, database backups, error logging, team security and feedback.
There are three types of feedback which can be left in Mendix which are: Issues, Ideas and Questions. Within the Mendix Sprintr any feedback can be changed between these three types, so if a user raises a feedback as an Issue when it would in fact be an Idea it can be changed. Before looking at each of these individually we’ll take a look at how feedback in general should be handled.
Handling Feedback
A regular refrain within development circles as issues occur is “raise it as a feedback” but if it remains unhandled then the app won’t improve and the amount of feedback can soon mount up. It’s important to keep on top it, and if possible make it part of sprint planning. Regularly look through the outstanding feedback and try to pick out what looks to be most important or necessary to the improvement of your application. Often it will be clear what the issue is to a developer and the feedback can simply be accepted and then planned for a future sprint. However, in the case where a feedback is either unclear or relates to an issue which is difficult to reproduce then you may need a response from the user who originally raised the feedback. Through the Mendix Sprintr platform comments can be added against a feedback and the original feedback raiser will be notified of this comment. This will move the feedback from being “Open” to “Handled”. Remember to keep an eye on both Open and Handled feedback to ensure that nothing is missed.
At the end of discussion over a feedback the choices are to Accept it, where it will become a story, or Close it, where no more work will be done. There are many reasons to Close a feedback, for example if the request contained inside has already been completed (or is no longer an issue due to a design change), if it’s already been planned or if it doesn’t fit with the application’s design plan. To aid in the setting of a closure reason the Mendix Sprintr has a dropdown menu (shown in figure 2) which will auto-populate the closure reason with some pre-defined text. The pre-defined text can then be added to if any additional information needs to be relayed to the person who raised the feedback.
Figure 2: Feedback closing options.
Issues
Issues relate to parts of the system a user feels doesn’t work or at least doesn’t work correctly. When dealing with issues, the first step is to make sure that it is an ongoing concern. For example, if a user raises an Issue that exists on the Production environment but this has already been fixed in the ongoing sprint then the feedback can be closed. Another example would be where user error has led to what appears to be an Issue in fact being the way the system is designed to work. When looking at Issue-related feedback remember that different users will raise feedback with differing descriptions so it can often be beneficial to accept multiple feedbacks around the same Issue and then create one main story with each of the other feedbacks as tasks within it. This way developers can keep track of the various different facets of the problem.
Ideas
This could be a new feature or a possible new way of approaching a current part of the application. Ideas will need careful consideration before being accepted but can often provide an new insight into how the application could be changed. For example, a member of the management team may have a request to automatically produce documents as part of a process to reduce workload within the company. Ideas are the type of feedback most likely to be closed due to them not fitting the design plan of the system. For example, if a business has decided that an expenses approval system should work in a certain way and a user has an idea to remove one of the steps then this is likely to be closed.
Questions
Within Mendix’s Sprintr, Questions work differently from Ideas and Issues because they cannot directly be accepted and turned into a story. Questions are useful to raise during development as they can ultimately be converted into an idea or issue and then a story. Questions should be raised for cases where the user is uncertain if the application should work in a certain way. Later on when the feedback is being reviewed it may then be decided that in fact the application should be altered and the Question will become an Idea or Issue.
Conclusion
Make sure you stay on top of feedback within your application, regularly review it and interact with the users who’ve created it. As you reduce the amount of feedback waiting to be handled you’ll be able to react more quickly to issue as they come in. Feedback is vitally important in developing any system and by managing it correctly you can make sure that there is always necessary work to do in any sprint.
Related Blogs
Drag