Traditionally, all testing, including assessing how easy real users can use your software, occurs in the very last phase of the project. But what if your team is using Scrum? What if they lack the UX capability to sufficiently understand and test the usability of the features they’ve produced? Do you need a significant amount of features before you can test or is there a smarter way to understand whether users will find your software easy to use and therefore value your product as much as their iPhone or iPad?
Matthew presented this case study at Scrum Australia in Sydney on usability testing in a Scrum project operating in an enterprise using Waterfall — a session that examined UX techniques and the psycho-cognitive factors that underpinned them to enable usabilty testing in the absence of dedicated usability practitioners. Specifically, Matthew looked at the question of timing of usability testing in Scrum in light of lessons learned on this, and a number of Scrum teams, and related techniques to deal with the conflict in ideology that often arises between minimal viable product, minimal usable feature, and what an end-user values.
[gigya src=”http://prezi.com/bin/preziloader.swf” type=”application/x-shockwave-flash” allowfullscreen=”true” allowscriptaccess=”always” width=”450″ height=”400″ bgcolor=”#ffffff” flashvars=”prezi_id=l35nt8rdgnuk&lock_to_path=0&color=ffffff&autoplay=no&autohide_ctrls=0″]
If your an agile coach, just knowing Agile, or Scrum, or how to set up a Kanban board won’t be enough to get you though the complexities involved in successfully performing the role and being an agile leader. Seek to expand your knowledge and capabilities and practice intentionally as part of your own continuous improvement.