Lost your License key?
Retrieve Your License
Log In to Balsamiq Cloud
Our new Web App
Go to balsamiq.cloud
Log In to myBalsamiq
Our vintage Web App
Log In to myBalsamiq
The Lean/Agile philosophy of "failing fast," continually testing and validating ideas, and working in incremental steps pairs well with the quick, iterative style of wireframing with Balsamiq.
Rather than taking weeks to build a fully-interactive prototype, Balsamiq lets you to create concepts and variations in hours, allowing you to test and validate much more rapidly.
Balsamiq wireframes also fit nicely into agile user stories, where a rough UI sketch can be supplemented by more detailed acceptance criteria.
In an article called "Using Wireframes with Agile User Stories" we propose a process for integrating wireframes into agile user stories that lets them easily adapt to the inevitable changes that agile allows for.
Read the full blog post here.
Leon for the Balsamiq Team
We'll send you just one email a month and share a ton of information that you'll get before everyone else. More info about the newsletter here.
We'll never share your email address or spam you.
Your email is never published nor shared.
Great write-up! Thanks, Leon. This post is very practical; I want to share it with every BA I know. I am also a big fan of balsamiq, and a former BA.
I agree that lo-fi mockups are the best way to communicate product requirement. It helps clarity but not over polished, which leaves room to encourage communication. I always use balsamiq mockups if the team is distributed. For co-located team, I like do whiteboard session with devs, draw the mockup on board and attach the photo to my user stories.
P.S. I came across this blog because I was doing research about mingle. Thanks for mentioning that. Mingle has added checklist support. You can also check off tasks as you go in Mingle now 🙂
Nice article Leon! I’m currently part of a Scrum team and i’m trying to find ways on how we can work with the BA to create useful mock-ups without going overboard together with our user stories. We seem to have discussion about how many variations of the mock-ups do we need… Hopefully we will come to an agreement and move forward in the right direction.
Hi Lion. Thanks for the article. Very useful. But I have a question:
If I got it right, you come up with the wireframe before writing the first story, in this case the epic “Customers”. Is that right?
I thought it was more appropriate to use wireframes to support acceptance criterias but only aftter you have made clear the business need first.
Here I understand that you are designing the page first, saying how it should display the UI elements before writing a single story.
Am I wrong?
Thanks for the comment and good question.
I use wireframes in at least 2 different phases. The first is when I reflect back to the PM what I’m hearing from them about the business needs. This is usually at the epic level or larger. It allows them to validate the design before approving it. Then, once the design has been signed off on, I use the same wireframes and split them up into smaller pieces to create stories from to support the acceptance criteria.
To summarize: there is a conversation that happens before what I wrote about above that I didn’t really get into. So, at this point the business needs discussion has already happened and the UI has been iterated over (at a high level, at least).
Hope that helps,
Enjoyed your article, Leon. Thanks!
You must have a favorite tool or two for writing and prioritizing your Agile user stories…and that work really well with Balsamiq Mockups of course.
I’d appreciate any recommendations you can send my way. Thanks.
I really liked Mingle because it allows you to insert images (e.g., mockups) inline with the text of the user story. Pivotal is another tool I’ve used. It doesn’t show images as nicely, but I like that you can check off tasks you’ve added as acceptance criteria as you go.
Thank you very much for such a wonderful article
This article was in my Pocket for days and I could read it now. I’d like to say it was worth reading it! This is a simple and user centric approach. You got points related do “Lean” and agile practices, really bringing value to each story. As a developer I must say most product owners can’t be so plain on what they want, as you demonstrated here. Thank you!
I’m just making this up, so I’m imagining some more details about this fake story. Let’s say the story title is “Technical Support would like the ability to view basic customer data”
The summary / story narrative portion could read:
“Many technical support issues are caused by incorrect data in the customer database. One way to help the technical support staff would be to allow them to easily view basic customer data so that they can verify its accuracy when they are on the phone with customers. This story lays the foundation for this work by creating a read-only table for the Admin screen. Future stories will enhance this functionality with the ability to search (see #1234) and edit (#1235) the data.”
You could think of it as an “elevator pitch” for the work the story is proposing.
Good article. Could you provide an example of your “summary / story narrative?” I.e. something similar to the example given for Acceptance Criteria.
I think the 80/20 rule applies across the board in software development generally. Its amazing how you can get 80% of the job done in 20% of the time, Equally I find that 20% of the problems take 80% of the time to resolve.
I’ve worked along these lines for a while but lately I have also learned how to write feature files for Cucumber testing.
They (or any similar framework) add some structure when writing criteria or describing actions that are hard to show in a mockup, but more importantly they also force you to think about edge cases or different starting situations, those that usually come up when developer has come about half way.
Here is a blog post with some examples, http://robots.thoughtbot.com/post/25650434584/writing-better-cucumber-scenarios-or-why-were
Pingback: My “Agile” experience | TsoDa Place
Nice article, Leon. Getting the right amount of detail in a story is truly an art form. The effort is most appreciated… even if it means looking after your dog 🙂
Toby, thanks for the feedback. I don’t think you should need to include more back-end perspective in the user stories since that shouldn’t factor into the acceptance testing. Sometimes, however, you need some bigger back-end tasks to happen first. I think it’s ok to create “chore”/”task” or “spike” stories separately to do back-end work that’s necessary to support front-end updates. Regarding the “as a…” format, I usually do write that in the beginning of the story (in the Summary or Story Narrative). I think it’s sufficient to capture the user’s perspective just in this section.
As a developer and an avid user of the Balsamiq Product , I take a similar approach with a healthy dose of “functional requirements” sprinkled throughout. This approach allows me to have meaningful iterative deliverables.
Nice article! I especially appreciate that you noted developers want to connect with the feature, and how important their sniff test is for validating why the story matters. Nicely done.
Really nice article – really enjoyed that. As a product owner, it is sometimes get the balance right with what the actually need developers need and what they claim they need, like big functional specifications. Just wondering if you think the user stories in the product backlog need refining beyond the UI requirements and delve more into the technical back-end functionality in order to get developer ‘buy in’? Also, I was wondering why you didn’t use the format of ‘As a…I want a…so that..’ to frame the user stories?
Totally agree in your idea of how details matters and its so true stories you are pinpointing. Great text, thx!