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″]
7 things everyone gets wrong about SAFe® and how to avoid them
Should you have business as Product Owners? Is the Release Train Engineer a Delivery Manager? Where do Project Managers go? Aren’t Epic Owners the executive? Everyone gets these things wrong. Find out how to avoid SAFe’s implementation traps.