Usability testing in Scrum environments — Presentation at Scrum Australia 2013

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″]
 

About the author

Related Posts:

Groupthink: the bane of high performing Agile Teams

What makes an agile team great and why? After coaching a number of teams in Scrum, we’ve now seen a number that, after a some months now, could be considered high performers. Some of these go bad and reject any external criticism regardless of how accurate that might be. Why do these teams go bad? Groupthink might have the answer.

READ MORE
search previous next tag category expand menu location phone mail time cart zoom edit close