A product owner that has screen mockups to work with has a powerful tool to elaborate user stories. Pictures enhance collaboration and understanding by giving the software development team an alternate method of receiving software product requirements from the product owner.
From a QA perspective, the mockups serve as a guide for testing the user interface to ensure that the user interface is developed as requested by the product owner.
It gets tricky though when the user interface mockup illustrates product functionality covered by several user stories. The one easy way around this is to just add the user story number to the mockup and use themes.
2 comments:
Thanks, Patrick, for bringing up this topic. I've been using UI mockups in all my agile projects. I see the same advantages as you mention.
But, I experience quite some disadvantages, too.
UI mockups done too early get outdated very easily. Maybe this is more a timing problem than a UI mockup problem, but as UI mockups are very detailed, they are very fragile, too. I would prefer the product owner and the developer sit together to do a prototype of the feature to evaluate how it shall look like instead.
Another issue I experience daily when using detailed specs like UI mockups instead of plain user stories is a kind of "monkey-see-monkey-do" attitude of the developers. Unfortunately, it happens often enough that a discussion about a user story is killed by the product owner because he refers to the mockup. He already put in all the detailed thinking, which lead to that mockup and does not want to explain all underlying ideas again. The developers miss the reasoning and discussion and have no way to add value to the discussion. That's a pitty.
All that said, I'm still looking for the perfect way to get all the benefits of UI mockups avoiding it's drawbacks.
Matthias - agileweboperations.com
Hello Matthias
Yes I agree that UI mockups can be fragile but the benefits outweigh the risks. We use iterations of UI mockups with the product owner to help the product owner work through issues. This requires some work up front but is also helps us reduce mistakes or missed nuances of a feature. When we work with the product owner we are user story centric, we may look at a UI that covers many user stories but we tackle the user stories independently. We annotate the UI screens to express the flow of the application; this is especially useful for our distributed team.
It’s a strategy that has served us well over many projects of multiple sizes and complexity.
Pat
Post a Comment