Posted by jc-Qualitystreet on 2012/03/01
The art of the specification in a agile context is above all collaborative. It’s also a matter of behavior.
As you know I like user stories. The format is a good way to express a requirement and to initiate the conversation between a Product Owner (supported or not by UX specialist, Business Analyst…) and the Team.
But of course, this short description, usually in one or two lines, is not sufficient to enable a Team to develop the functionality described… (see agile PROTOTYPING)
A generic template that must be adjusted to your own conditions of readiness
In short, the idea behind this precious checklist (inspired by Lisa Crispin and Janet Gregory‘s book) is to facilitate the job of the Product Owner.
With this checklist, the Product Owner identifies the key elements that must come (in his context) with a specific User story. For example, these important test cases must be envisioned or a link to UX stuff, wireframe of the screen, UI library or a prototype must be provided.
This is also the place where you can start describing required business rules (the business rules paragraph was crucial for financial and supply chain projects I was involved in and we linked it to an ATDD approach).
The Product Backlog Refinement (the » forgotten » 5th Scrum ceremonial for grooming activities 🙂 ) or other dedicated collaborative workshops are good opportunities to work on the checklist and to make sure that a specific user story will be ready to be taken and developed during the next sprint.
Product Backlog Refinement Agenda
Then, several days later, first day of the new sprint, the sprint planning part I (scope definition) will be used to confirm the various elements, especially the conditions of satisfaction, and the engagement of the Team to develop, by the end of the sprint, the user stories discussed.
Remember: feedback and collaboration!
Posted by jc-Qualitystreet on 2011/11/26
DAY 1 was just amazing… see my previous report: Agile Testing days: Day 1 What a fabulous day!
… to me the second day of the conference was less intense. Keynotes were great but I was a bit disappointed by some sessions I attended…
Esther Derby People & Patterns (Keynote)
According to Esther, a basic problem is that system problems are usually associated with persons and persons with problems attributed to systems.
« If you really want to create change in the organization you can’t only look at events you need to look for patterns »
Esther said that within one team, one can find several groups, several patterns and structures almost invisible.
Then she explained how Agile can help the organization to identify the existing patterns. According to her, there is a necessity to understand patterns of behaviors, then to shift the pattern. Her approach consists in collecting the factors (neutral and potentially measurable), brainstorm them, diagramming the effects, then identify patterns and look underneath the events.
And, always wondering WHY (the most powerful question)…
Interesting quotes:
« In the business world you are paid to be decisive. It’s better to be certain and wrong than uncertain and right. »
« If you want to see what’s going on, you don’t watch the person who’s speaking – you watch the others in the group. »
« Focus on people never brings change »
A good keynote but not as inspiring as the others.
Raquel Jimenez-Garrido « ATDD and SCRUM Integration from a traditional Project methodology »
An attractive title and the description looked good in the program but after 15 minutes still nothing about ATDD and SCRUM! Worst, 30 minutes after the beginning of the session Raquel was still in the process to describe elements of context! We understood that her team had a lot of motives to change…
Then, she explained the difficulty to achieve the change of methodology, described the problems they faced (for example during a sprint0) showed the Product Backlog used, and discussed the selection of the tools.
Her conclusion:
« The application of ATDD techniques was key to improving product quality due to the nature of the project »
Stevan Zivanovic « Do we just Manage or do we lead »
Stevan clearly made a distinction between leadership and management, with these two definitions
- The leader is a person who rules, guides and inspires other
- The manager is a person who has the control or the direction of an institution, business business, etc., or of a part, division, or phase of it
The talk focused on leadership, what makes a good leadership and its various dimensions…
« Don’t need to be a manager to lead « …
Of course, you don’t, but personally I expect my managers to be good leaders too, and many agile teams also expect it from the middle management.
The elements presented by Stevan were interesting: the different levels of contexts (culture, organization, team, you…) and what it takes to be an effective leader… But, the radical distinction (I perceived) between manager and leader didn’t make me comfortable. And I was not surprised that at the end of the talk, one person of the audience asked this essential question :
« What is the role of managers in Agile? »
The link between agile management and leadership was not clearly stated. To me (see this blog post on agile & lean management) the Agile Manager needs to show leadership especially for three major activities:
- Create a relationship of trust, develop an motivate people
- Create an environment of success and energize change which means communicate the vision, give a direction, adopt the appropriate style of management (see Jurgen Appelo, 7 levels of delegation)…
- Initiate, support and animate communities of practices
This is what I observe during my agile coaching activities but things I didn’t hear during the talk… However, Stevan is a good speaker and session was good.
Elizabeth Keogh « Haiku, Hypnosis and discovery: How the mind makes model » (keynote)
Elisabeth encouraged, during an interactive introduction, the attendees to create their own Haiku and to discover the Haiku moment (the moment when our mind makes a model)…
The most famous Haiku :
Furuike ya
Kawazu Tobikomu
Mizu no oto
In english:
Old pond
a frog jumps in-
The sound of water
Then still in a very interactive mode, she did hypnotherapy on stage (with @huibschoots)…
Interesting to see.
« The contexts depend on the context »
According to Elizabeth, we observe data, we filter data, we generate assumptions, we draw conclusion, we build beliefs based on pattern. The problem is that the filters we use are based on our beliefs! When I change my beliefs I change… Very inspiring.
Then Elisabeth discussed the art of BREAKING THE MODELS and Real options (to me, a very efficient tool), and how this approach helps us to give us different models….
Fran O’Hara « Effective Agile Test management »
Once again a session dedicated to management (testing management oriented)
Some elements of the pitch attracted me like « Test managers want to know what happens to their role when teams are self-empowered and what a test management process looks like in agile context »… and Fran went straight to the point (I really liked it) on the first part of his talk.
« What the test managers do in Agile? »
Very interesting (cultural shift, mindset shift, servant leadership, culture of leaning….)
Fran listed the responsibilities of the Test manager :
- Support tester capability within the agile team
- Remove organizational obstacles
- Agile test Startegy
- Agile Test process
- Test tool standardization
To me, the first category « Support tester capability within the agile team » (from firing to training, career development, performance to community of practice) was just too large. It probably needed to be split and discussed more in details…
Then, Fran discussed Agile Test strategies, Test management Process, Test management Issues (including metrics)… Good but … he spoke often too fast for the French attendee that I am 🙂 Therefore he was in the hurry at the end of his talk!
His slide with the « do and don’t » was a good summary: I appreciated.
Cecile Davis « Get your agile test process in control »
Another session related to management. Cecile wanted to talk about control, « tight grip or let go? », and the need for management to find a balance between these two extremes.
Cecile led the audience through an interactive exercise to find the balance between trust and control (blind / Seeing pairing), a kind of exercise sometimes used in agile training. During the second exercise audience was split in three large (too large?) groups to find out and generate, from a vision and business goals (based on the IKEA brochure), product properties. Well, I didn’t really see the link with agile management, control… not so good.
Gojko Adzic » 5 Key challenges for Agile testers tomorrow » (keynote)
A really interactive session with the most influential tester of the year… and real showman!
Technology evolves, things change fast and so, according to Gojko, testers are now facing new challenges:
1. Shorter delivery phases
Gojko first introduced the « Flickr » example with its frequent deliveries (multiple times a day).
Multiple times a day
Frequent releases (for example every 2 weeks) are not only a trend. There is no crazy website anymore. It’s now a reality that obviously impacts the testing activity.
« At the moment you have done testing more than you need »
« We need to accept certain risks »
To help us, Gojko introduced the Agile Risk Donut…
« If only have 2 sec to eat something which part do you eat? »
In addition to the risk based testing, you need to engage business people, identify business goals and understand where risks are. A good tool for that is « attributes capabilities matrix » by James Whitaker.
2. Agile is now mainstream
Agile is now everywhere with an important inconvenient: we lose more and more the meaning of what is being agile. And often when going agile, the BA becomes the PO, the Project manager becomes the ScrumMaster… and yeah…
« We do Scrum! »
So when working with people, we need to make then ADOPT the principles and ADAPT the practices.
3. (Provide) faster feedback
Faster feedback is not only good but needed. Gojko gave us an example of situation where the tester becomes the bottleneck (doing testing for all programmers) and the way to solve the problem by making the tester teach exploratory testing to developers…
« Your job is to teach the people how to test »
It accelerates the feedback
4. Large enterprise projects
Many companies are trying this scalability. What to do if we need to scale? Actually we need different ways to scale. A good option, according to Gojko is to refer to context mapping (element of DDD, Domain Driven Design, see Eric Evans’s book, from chap 14 🙂 ). For being involved as an agile coach in such a large projects, I can recommend you Craig Larman/ Bas Vodde approach which is an excellent starting point.
5. Validating Business not software
There is now a huge push in the software value output but
« How do we see we’re delivering business value? »
« How to figure out where is the value? »
Two things help:
- Effects maps, a very powerful tool, introduced by Gojko the day before
- Measuring, the key, and for example crucial in the lean Startup approach (Eric Ries)
The good point is that the testing community becomes to be important to the business (to draw the context and to measure)
Gojko provided us with a useful summary at the en of his talk:
- adopt principles and adapt practices (I really like that one)
- teach others how to test
- help business define and validate actionable metrics
- look at risk/ value areas. Visualize it!
- draw up contexts to inform testing
Posted by jc-Qualitystreet on 2011/11/19
The Agile Testing Days (Nov 14-17 2011) is the annual European conference for and by international professionals involved in the agile world. As the French Ambassador of the conference taking place this year in Potsdam (near Berlin), I couldn’t miss it. So, second participation, high expectations and absolutely NO DECEPTION!
This first day was I think my best conference day ever! So thanks to Jose Diaz, and his team, thanks to the speakers and participants.
After a very good full-day tutorial given by Jurgen Appelo (« Agile management: Leading Software professionals »…. a course that I do recommend in a 2 day format to all managers) and a dozen of games/exercises to try « At Home »…
Jurgne Tutorial.. Metrics Matrix to try
the conference Day 1 opened with Johanna Rothman’s keynote…
Johanna Rothman « Agile testers and test managers: Now what? »
This keynote was the first of an impressive set of amazing presentations
Agile management is a hot topic to me since I do more and more agile coaching with line managers. I’ve explored the domain and of course already read Johanna’s books and articles. However, I found this « testing oriented » presentation very valuable.
Agile Test Managers Keynote
Johanna first discussed the changing role of the testers in the agile organization. The agile tester looks like the First Class Tester (she previously described in 2003), as they, for example, work with developers from the very start of a feature…
« Testers ask questions… are curious »
The second part of the talk was dedicated to Agile Test managers…
« Agile test managers are leaders in the organization »
The key activities:
- Manage the project portfolio
- Remove organization obstacles
- Build trust relationships
- Lead hiring decisions and process
- Build the capacity of the organization
- Build communities of practice
Interesting thoughts
« Have management iterations » (To try!)
« Allow managers to see the system »
« Instead of individual reviews build a trusting relationships share the strategy share the profits »
« What keeps people in job? Trust »
« No micromanagement meet often one on one to build a trusting relastionship »
David Evans « What testers and developers can learn from each other? »
The presentation was efficient and David, as a good speaker, made a good use of analogies:
« Thinking you can improve quality by doing more testing is like thinking you can loose weight by weighing yourself more »
An effective analogy
With ease, David focused both on things developers can help testers learn and things testers can help developers learn for the benefit of the whole team. The parallel was interesting. After pointing out ironically that ISTQB certification is mostly useless, David discussed common issues like coverage and concluded with things we all need to learn:
How we learn – David Evans
« Testers are friends »
« Teams need testers like people need friends » (I like that one!)
Rob Lambert « Do agile teams have wider awareness fields? »
« Not always »
but Agility gives you an environment to be a first class tester added finally Rob.
A good presentation that Rob was able to make interactive. I appreciated.
Rob started by introducing the concept of awareness and distinguished social and personal awareness, which was useful.
« Awareness is the ability to feel, perceive, know and be conscious of yourself and the world around you »
Awareness
Other interesting thoughts…
« Awareness is the first step to change… »
« You need to know yourself and you team »
« You need to know your limits »
I like very much the idea of Learning Roadmap (closed but maybe richer than my To Learn List).
Learning Roadmap: What a good idea!
And finally, Rob pointed out the grower importance of social media and social tools (like twitter) as modern ways of widening awareness. I can just agree 🙂
Linda Rising « Who do you Trust? Beware of your brain »
Last year, I didn’t notice it immediately but Linda’s keynote gave me inspiration for a year. This time, once again, she did the job, and I must admit that emotion was in the air (and in me) at the end of her speech! She is a fantastic storyteller!
Based on experiments coming from the social sciences field, Linda shows us how quickly we categorize others, how quickly we naturally stereotype and label other people…
« We continually sort others into groups and out-groups »
The bad thing is that stereotypes and their expectations are not only a source of conflicts but also can affect performance…
« Stereotypes are prophetic »
The good thing when we look at the results of social experiments is that Humans like to be in small groups and quickly develop identity, no matter countries, cultural dimensions or even religions…
« This is the good news we like collaboration »
This is what we call Social Interdependence. The benefits?
- increased effort to achieve,
- positive relationships,
- improved psychological health…
And you know what? agile practices are practices that help. Therefore, sharing a common goal, as well as be trusted and respected are the keys.
« You don’t to be my best friend »
Linda ended her presentation with 2 good examples (« Trench warfare » and « primates ») showing reasons for hope and nothing is carved in the rock.
Happy Ending
Huib Schoots « So you think you can test? »
This session wasn’t originally on the program. A good surprise! Huib is an experienced and passionate tester. His talk was dedicated to the factors that can help you to become a better tester. Huib listed three main activities:
- Adapt to context (context driven testing…)
« There is no best practice »
- Collaborate. Most of the job of the tester should be to ensure that the right testing is done (executing tests should be a small part of the activiy)
- Learn & Practice. Huib pointed out a set of learning options (Books, conferences, testing dojos, week end testing, pair testing, collaborative workshops, peer workshops…)
Passion…
« You should train and practice »
« Be passionate » (to me, PASSION makes THE DIFFERENCE)
and one of my favorite quotation of the #AgileTD:
» If you want to do a good job I think you should invest in yourself »
Be passionate as Huib is
And finally a good question, why don’t we have a Testing coach?
Gojko Adzic « Product Management using Effects Maps »
This session wasn’t originally on the program. A good surprise too! Gojko presented the Effect mapping, a visualization tool invented by Mijo Balic and Ingrid Ottersten.
Effect mapping supports product management activity by focusing on business goals. It enables high level project visualization, helps to deliver software iteratively (starting by the fastest simple way), and reduces user stories management issues…
« People horribly misuse user stories »
« As a system, I want… a system doesn’t want anything a system wants to sleep »
The starting point and the first level of the map is always the WHY (the business goal, how the business will be different 6 months from now if we achieve well).
Effect map
Then, are drawn the next levels:
- WHO (can contribute to the business goal)
- HOW (can they help us)
- WHAT (we can do as a team to support this activity)
Once the map created, deliver the simplest thing to deliver (a path) and measure the effect (very similar to the Learn Startup approach introduced by Eric Ries…). IT should be seen as an investisment, not as a cost
The effect mapping, a tool to try…
Janet Gregory – Lisa Crispin « AppendixA: lessons learned since Agile testing was published »
We all know Lisa Crispin and Janet Gregory, authors of the famous Agile Testing book…
Lisa Crispin… later at night, at the party and ready to announce the award for the most influential agile tester of the year… DO YOU BELIEVE IT?
For this keynote, Janet and Lisa decided to discuss 5 Hot topics related to agile testing:
1 Feature Acceptance
Working feature by feature makes you often forget the global picture: during her talk, Janet used the puzzle analogy and stressed the necessity to understand the business value of a feature to deal with this issue and help prioritization. Establishing story tests but also defining story doneness, feature doneness are crucial.
2 Automation
Collaborate to automate and overcome impossible challenges. In term of test strategy, Lisa and Janet reminded us that context is everything, and so that for example, the well-known test pyramid should be adapted to the specific needs of each organization. According to them, « tests as documentation » is the only documentation guaranteed to be up to date… (as long as they run green).
3 Large Organizations – large Teams
In the case of large organizations, Janet and Lisa pointed out the necessity to consider other teams.
Key challenges : Multiple Teams
« You need to extend your family beyond your project team »
I totally agree! (see devops movement)
4 Distributed Teams
The world changes, and today’s the business is more likely distributed. A fact that I can easily confirm doing some agile coaching in various situation like French/ French distributed sites, French / Indian context or French/US/ German context. For such a context, my opinion is that reducing the distance is the key… Lisa and Janet presented 3 practices to succeed: establishing relationship, taking advantage of the technology (the virtual team member…) and experimenting!
5 Culture & Continuous learning
Agile is all in learning. Yeap!!! According to Lisa and Janet, culture is even more important that we thought: personal safety and allow people to make mistakes are essential. Janet insisted also on the important role of Play in the learning process. An element I am also convinced… as well as the necessity to be CURIOUS
« I really encourage you to be curious and learn new things »
« I like to see testers to be curious »
The last part of the talk was « attendees » oriented! Janet and Lisa wanted to hear about the stories of the attendees (« the Agile Testing book », « Testing dojos », « Twitter », « Tests & Feedback »…)
And Finally the Party to close the day
Some pictures of the funny party taking place in the evening (during when Gojko Adzic received the award for the most influential agile tester of the year). I enjoyed the show, the performers, the place, liked the beers and the discussions with the frenchies: Laurent, Gabriel, Patrice and Elalami…
So, MY ROTI (Return on time Invested) FOR THE DAY: 5
Posted by jc-Qualitystreet on 2011/04/19
A user story is a requirement of the system to be developed, a brief description of a feature as viewed by the user (Role → Goal), very popular on Agile projects.
« As a customer, I want to book a train ticket to go to Paris »
User Stories are usually associated to the 3C rule, quality criteria (INVEST) and the « User Voice » format…
As a <User Role>
I can <Goal>
So That <Business Value>
user stories INVESTEd… goal oriented and customer-centric
Each user story must be estimated (by the team) and prioritized, but also SMALL ENOUGH to be delivered in a sprint (usually smallest teams take at least 3 stories per sprint). This is a necessity if you want to observe real benefits in terms of value delivery, visibility, flexibility, feedback and continuous improvement.
During my agile coaching activities, I am regularly asked to help the team and Product Owner to split user stories into smaller ones.
Here are the 10 strategies I use to effectively split large user stories:
1 Steps of a workflow
The user performs a task according to a well-established workflow. The large user story is split according to these steps in order to be developed incrementally. Each step has its own user story.
2 Scenario
By splitting a user story by scenario, you get a User Story for the main success scenario and other user stories for any errors or alternative paths:
when x happens, then…
when…, then
3 Sequence in a scenario
The case is more precise, you divide the story according to a specific sequence in a scenario.
4 Operations
Splitting a user story by operations is often the most obvious way to decompose. A CRUD (Create, Retrieve, Update, Delete) feature is a good example. Separate the CRUD or group two operations in a user story may be appropriate … to create an account, to view it, edit it and delete it.
5 Size or type of data
Pretty obvious too. You divide large user stories according to the type of object (e.g. various account types, messages in English, French, Spanish…)
6 Type of input, output or configuration
Variations in terms of material or not, on configurations but also in terms of input means or User Interface can lead to new and smaller user stories.
7 Persona or role
This time, you choose to break down the user stories based on the role or the persona who will use the product. This is a very good option easy if you use the user voice format or the Persona approach. The story mapping activity is a good way to visualize it.
8 Level of knowledge
The level of knowledge acquired on a feature is a good criterion of decomposition… You can get a specific story for what is known, another one for the unknown (leading to a spike and exploration activity)
9 Level of complexity
For example a user story can describe a feature in the simplest way of implementation, others will follow by a greater level of complexity or detail.
10 Level of quality expected
Performance, Security, Usability … these non-functional requirements are usually described in the elements of conversation, of a specific user story. There are conditions of satisfaction, but they can also help distinguish between these user stories (eg display it in less than 60 seconds, less than 30 sec; data in real time or not …)
Illustrations will be added progressively. If you want to participate, please submit your comments with your example and strategy number…
Posted by jc-Qualitystreet on 2011/02/22
…that is all you need to work effectively!
The mockup activity (or prototyping) is part of a user-centered design approach. And the « Wireframe » has become over the years one of the most favorite artifact of User Experience specialists to communicate a concept, verify design assumptions and testing various options or validate ideas and usability decisions …
Example of wireframe with Balsamiq: my french blog
Wireframe: the real issues
A wireframe is a « low fidelity » prototype. This non-graphical artifact shows the skeleton of a screen, representing its structure and basic layout. It contains and localizes contents, features, navigation tools and interactions available to the user.
The wireframe is usually:
- black and white,
- accompanied by some annotations to describe the behavior of the elements (default or expected states, error cases, values, content source…), their relationships and their importance,
- often put in context within a storyboard (a sequence of screens in a key scenario)
- refined again and again
- used as a communication tool serving as an element of conversation and confirmation of « agile » user stories
Various tools can be used to create wireframes (with different format and level of fidelity), from the simplest to the most sophisticated ones, free or not…
Just enough is the best…
I’ve seen too many projects (led by traditional development methods) in which a wireframe was one of the numerous artifacts of the project, just additional documentation, created solitary by a single person, aiming at replacing dialogue and conversation between people. What a waste…
But I’m also always amazed when I intervene on a agile project as a coach to observe that wireframes are rarely used. Moreover, design & specifications workshops, interactions, conversations, feedbacks between Product Owner and team are not effective, partially or not done. What a waste…
The winner of the « the best prototyping tool award » is actually… a Trio!
The real strength of the wireframe lies in its ability:
- to be a communication tool, used during a workshop to facilitate discussion with developers, testers and business actors (Product Owner).
- to be created collaboratively, in order to enable everyone on a team to have a shared picture ,
So, wireframes help to generate feedback, to see potential problems with an interface and to clarify conditions of satisfaction.
For these reasons, simple PAPER PROTOTYPING done collectively,
quick collaborative wireframes on the WHITEBOARD,
and rapid sketching activities with BALSAMIQ,
are by far the most effective.
On Agile projects (with short sprint lasting 2 or 3 weeks), this is not only an option! Rapid and valuable prototyping in order to foster collaboration and elicit rapid feedback is a must.
Exploring, illustrating and understanding ust enough, just in time… wireframes should be adjusted in terms of scope, details, timing and level of fidelity with a special focus on feedback, collaboration and interactions. This is probably the reason why I abandoned tools like Microsoft Visio and PowerPoint or Axure RP Pro or PowerPoint that have long been my preference but which are mostly inappropriate in the Agile contexts …
Paper Prototyping
Paper prototyping is probably the fastest and easiest form of wireframes but not the least effective. Direct, simple, visual, cheap, enabling rich feedback, paper wireframes focus above all on collaboration and proximity.
Paper (sketch): easy to create a low-fidelity wireframe
Complexity of the format varies from one context to another, as highly developed paper prototypes can be created with proper equipment, good preparation and facilitation. Interactive paper prototyping sessions offer other benefits: direct manipulation, interactivity, playfulness and creativity.
Paper prototyping
Larger collaborative workshops (focus on prototyping) can be very valuable both for design and testing activities.
Design workshop. We divided the group into sub-groups (45 minutes preparation for the first round - 15 minutes presentation)
Simplicity is both a value and a strong principle of agility. Paper prototyping is a solid practice of Agile teams
UI paper
Witheboard: just in time, just enough…
Teamwork on the whiteboard is one of the most efficient form of communication.
Communication Modes Effectiveness - Scott Ambler
Collaborative specifications workshops around the whiteboard are intense and highly valuable:
- they create a collective dynamic leading to a stronger decision
- they are a incredible source of discovery and creativity
- they are interactive, playful, never boring
- they focus on visual and touch through direct manipulation
Several specifications workshops take place during an agile sprint.
Some are dedicated to the scope (user stories) of the current sprint; other (also called Product Backlog refinement) serve to explore, refine, model collectively user stories envisioned for the next sprint. Some teams I coach organize this specification workshop, just in time, the last day of the current sprint (i.e. Friday afternoon) after the Sprint review & Retrospective in order to be ready for the Monday sprint planning.
Other teams organize it in the middle of the sprint in order to have time for requirement exploration, testing, business modeling or quick user research….
Whiteboard prototyping
Design & specification workshops give the necessary context and conversational elements so crucial to User Stories. They enable to illustrate and clarify the conditions of satisfaction while delivering valuable examples.
Take a picture of the results with you camera, and you have a useful element to associate with your user story description written in the wiki!
Balsamiq Mockups
Balsamiq is an electronic tool that I recommend to agile teams (complementary with paper and whitebooard). Easy to use and allowing very rapid sketching, the application presents a large library of UI components (build-in and from the users’ community), many templates, export possibilities and precious plugins for Confluence or Jira users.
Example of wireframe with Balsamiq
I use the tool with several co-located team and in distributed contexts offshore via screen sharing: in both cases the contribution of the tool was welcomed by teams and Product Owners « a useful tool that serves human activities« .
The sketchy format also has its interest: it lets you focus design conversations on functionality. No risk to forget the reality!
You must focus on your working software deliveries to measure you project progress. Wireframe is a communication tool.
Balsamiq Mockups can be used to model any type of interface: web portal and websites, software application, mobile interfaces…
This is not a free tool but the price / quality ratio is excellent.
