Mockups usage

Scrum enforces a strong collaboration between the developers team and the Product Owner.
By working on a single product backlog, where all requirements, bugs and impediments are stored, constantly  updated and visible by all.

This works great.
However, some observations found during sprint planning sessions:

  • Sometimes stories, requests and intentions are misunderstood by the developers team.
  • Without visual support, the developers team tend to ask fewer question and acceptance criteria list is not complete
  • Product owners ideas are clearer and more accurate when he draws a canvas of UI prior to sprint planning

That’s why I strongly suggest the PO to use a mockup tool.


  • Help the PO eliminate bad or wrong ideas
  • Think more about acceptance criteria
  • Give the PO a tool to communicate precisely his ideas to the developers team


  • PO might think that his wireframe is the final say on what the UI will look like
  • It might drive away the focus of Domain Driven Design toward a Screen Driven Design.

So while mockups tools is a great communication tool, you have to ensure that your Product Owner understand that his ‘design’  is only for communication and clarification. It will not be cloned or copied ‘as is’ in the application.

At nVentive, we use a very lightweight and friendly tool called ‘Balsamiq’.
Easy to use, cheap cost, great features, can be integrated in several other application and portal.

I really like and approve their  mockup manifesto:

Examples of Balsamiq mockups

However, there is other tools on the market.

Other mockups tools comparaison article:

In a nutshell:
- Continue and keep your Domain Driven Design approach. Your domain model should be your first communication tool.
- Add mockups tool to your conversation to ensure clarity, and to help your team ensure that acceptance criteria are well discussed during Sprint Planning (and at other sprint moment if you sense confusion or gray areas).