I’m helping a customer on their first agile project, and at the moment we are focused on getting the backlog into a state that development can get started. I’m a little late joining the team, a lot of work had already been done, so I’m helping ensure that all of the pieces are in place.
The business analyst I am working with has written a lot of requirements, but is new to writing user stories. He is acting as the product owner and he has a first draft of the stories, thus we have a good place to start. For the most part, the stories themselves are good, what is missing is acceptance criteria and other supporting information to help ensure that the story is “complete”.
When I say “complete”, I mean that the story has all of the information the development team may need so they can understand what is needed by the business. This should include not only acceptance criteria, but can also include process flows, decision tables; essentially any additional information that is deemed as helpful.
We do have some process flows, which helps tremendously in understanding how the application will be used by the business. With that knowledge, we started to write our acceptance criteria. We thought of what the user would be doing, how they would want to know that the action taken was complete. We thought about performance. We thought about happy path as well as the not-so-happy path, and what type of error messages would be helpful.
This is an application that is for a tablet, which is new territory for the development team. No screen mock-ups existed so I suggested that we create some, to help the developers understand how we wanted the screens to look (and not to leave them to their own ideas of good UI design). We started very low tech, with paper and a marker. It’s a great place to start, and no one ever said that we had to use special software to create a mock-up!
As we started to draw, we suddenly found a lot of additional acceptance criteria. One of the features is the ability to scan a bar code. This led to a great discussion about how we expected that to work…which of course led to additional acceptance criteria. As we continued to draw, it led to additional questions, such as what if we want to cancel? Where should that button go? Once the scan is complete, what does the next screen look like? What data should be on the next screen? And the list of questions continued.
Once we were done with our paper/pen drawings, we then created the mock-ups in Balsamiq. If you are not familiar with this tool, it is a great tool for mock-ups, very easy to learn, and not expensive at all. It is geared more towards those of us who are not UI designers, it will never give you a picture that would look like the real thing, but it is awesome in giving a picture from which development can start to work. Once we had our mock-up in Balsamiq, we then attached it to the user story for development.
The moral to the story is, that as we started to draw, we found a lot more information that needed to be documented and shared. A picture is definitely worth a thousand words, but it can also be used to help find those thousand words.
