Know your Target Audience
One of the primary indicators of whether a web site or application becomes successful, useful, popular, and actually used is its ability to satisfy its users. How do you satisfy users? By knowing who they are, understanding their mindset, putting ourself in their place, and building user stories around that point of view (POV).
Enter the User Story
With agile development, particularly scrum, we have a concept called User Stories. The most common User Story format is:
As a <category of user>
I want to <do something>
So that I can <get something>
Writing out this User Story on an index card (or in JIRA if you are running a distributed scrum team) almost forces us to think about the needs of the user and understand what they want to do and why. So, when a developer is coding a task that supports the User Story they can have the user at the center of their design and development framework and mindset.
Definition of Done
One of the fuzzy things about software development is knowing when it is done. The expectation of done for a product owner is often quite different than that of the developer. So, it helps to define what done looks like and to produce some kind of binary test that a third party person can perform to declare whether or not a User Story is indeed done.
When a developer tells me that something is done, my first response is usually, “b******t!” it is ready for testing. Obviously, I would hope that a developer tests their own code but we all know how when we spend too much time on a task that we can’t see the mistakes and typos staring at us in the face. So, it is important to get another person who did not code the User Story to test it to verify if it is actually done or not.
With agile, individual developers are usually responsible for tasks but the entire team is responsible for the User Story. Why? Well, often User Stories require multiple team members to contribute; i,e., designer, front-end developer, back-end developer, tester, etc., Moreover, a User Story is often broken up into individual tasks to be performed by individuals or pairs of pair programmers.
By far, the best way to test a User Story is to find a user and ask them to perform the story. Don’t coach them, don’t explain anything, just ask them to perform the story and take notes. This is at the core of User Centered Design (UCD) and Usability Testing or User Testing affirms whether or not you successfully performed User Centered Design.
Herndon, VA – Agileana is a lean agile web development shop in the Washington DC metro area holding a GSA IT 70 schedule and 18F Agile Delivery Services Blanket Purchase Agreement (BPA).