Soft Illuminations, Inc.

User Stories

Michael Jabbour — Mon, 06 Apr 2009 12:00:32 +0000

Why we use them, and a few tips on writing superb stories of your own

User stories are the essential element of our development process. They provide a concise way of communicating the requirements, features, and user experience of an application. Once our clients learn to communicate requirements in user stories, they become active participants in the development of their project.

What is a User Story

A User Story describes functionality that is of value to the product owner or user of an application. There are three crucial elements within every User Story:

a concise, written description of the functionality
a short conversation that helps flesh out more details of the story
a test for the story to determine its completeness

Why a User Story?

User Stories emphasize verbal communication among the development team and the product owner. As a result, the client remains an active participant throughout the development process, fully integrated into the creation of the application. Since such strong emphasis is placed on communication by way of User Stories, the product owner is able to add or change features of the project on the fly. We often find that when our clients really take hold communicating requirements in user stories, they realize the full potential of their project and feel they are truly directing the development process.

There are two main reasons why it is imperative that our clients write their own User Stories

Since the client will be the party responsible for prioritizing the stories in upcoming iterations, each story must be written in terms of business-value to the client, and not in technical jargon.
Clients are the primary visionaries for their product. In this respect, they are the best in describing the behaviors of the application.

Estimating User Stories

User Stories cannot be placed in any order before considering their cost. We estimate our stories based in Story Points. Story Points are a way of assigning a value to the story based on the story’s complexity. For instance, a story estimated at 6 story points will take twice as long as a story estimated at 3 story points. Story Points allow us to easily create and estimate a release plan. By working by Story Points, we can easily track our teams velocity, the rate at which we complete story points. Knowing our velocity enables us to provide our clients with a more accurate time table of their project’s completion.

Effective Story Writing

One of the best ways in which to write a User Story is to use User Role Modeling. User Role Modeling is the practice of creating fictional characters who will be using the application. It is important that these characters, or User Roles, as we refer to them, all have distinct purposes for using the application. In this respect, we are able to put ourselves in the shoes of the end-user of the application to gain new insights into how the system should operate.

Take for instance a job-search system such as Monster. From a development perspective, it is important to understand the different parties who would use such a site. User Roles should be defined for job-seekers, employers, recruiters, and so on. For each role, we like to assign names and create a fictional set of circumstances for each. To use the job-site example, we could create the role of “John”. John is 27, has recently lost his job, and is now looking for a new career. We ask ourselves, how would “John” use this site? What would be important to him? What exactly would he be looking for? In asking ourselves these questions as they pertain to a distinct User Role, we can create effective User Stories that will address the real needs of end-users of the application.

While writing User Stories, we consider as many roles as possible and identify the goals that each user has for interacting with a system.

A few more tips

Stories should be goal-oriented

Every story should end with the user feeling as if they have accomplished something. We refer to this as writing a “closed” story.

Write the stories in an Active Voice

This makes User Stories much easier to read and understand. For example, instead of writing “A resume can be posted by a job-seeker” write “A job-seeker can post a resume”. In this respect, you are viewing the system from the viewer’s perspective.

Have your customers write the stories

It is important to empower your clients with the ability to write their own stories. The development team should always help out, but the product owner is always best positioned to describe the behaviors of the system.

Keep them short

Remember to keep the stories as concise as possible. Ask yourself, what is the sole purpose of this story? A story should effectively communicate one feature of the system only.

Agile People

Sherrod Faulks — Wed, 25 Mar 2009 14:44:26 +0000

I spend a lot of time describing what we do and I’ve started noticing trends in the documents and diagrams we make. The idea of “Agile People” keeps coming up. We often explain Agile Methodologies from the perspective of roles – who’s who, who does what, and who does not do what – that I decided to standardize our visual language with a set of images:

You can see an example use on our services page. I invite everyone to change, share and use these images, just give us some link love in return!

Agile People is released under the Creative Commons Attribution-Share Alike 3.0 US license.

Download Agile People as a Photoshop Document

Scrum Illuminated

Michael Jabbour — Fri, 13 Mar 2009 14:27:18 +0000

At Soft Illuminations we use the Agile methodology of Scrum in seeing our projects through. Scrum is a simple set of rules that can be applied while managing software projects. By requiring Project teams to adhere to these very simple rules, Scrum creates an environment of collaboration, innovation, and synergy. Be aware that Scrum does not teach new and innovative ways to develop software. It only defines the rules of engagement.

Communication Breakdown; It

Agile Methods

Michael Jabbour — Fri, 13 Mar 2009 14:20:01 +0000

At Soft Illuminations, we never let the opportunity to teach customers pass us by. We employ Agile methodologies and practices in developing software. It is absolutely necessary we educate our clients about how we innovate for them. It is my hope that this article serves as a solid reference for those unfamiliar with Agile Methods.

Agile

Agile, when used in reference to software development, is a group of methods and practices that are based on common principles. Agile methodologies foster a team

Extreme Programming

Michael Jabbour — Fri, 13 Mar 2009 14:10:34 +0000

Extreme Programming, otherwise known as XP, is a method of software engineering used in Agile software development. Here are some of the most popular practices of XP

Continuous Integration

Continuous Integration is the practice of integrating code early and often. The main objective is to eliminate time-consuming rework thereby reducing the cost and time of a project. If executed properly, continuous integration has been shown to drastically reduce the costs of a project while adhering to project timetables.

Pair Programming

Pair programming is a development technique in which two programmers work together at one keyboard. One types code (known as the driver), while the other reviews each line of code as it

Agile

Michael Jabbour — Fri, 13 Mar 2009 13:31:49 +0000

Being agile means having the ability to move quickly and adapt to change easily. Soft Illuminations provides custom solutions for our clients in the most effective way possible by employing Agile Methodologies in developing software.

Out with the old

In business, agility means the capability of rapidly and cost efficiently adapting to change. In software development, constant change is inevitable since it is rare that requirements remain static throughout the life cycle of a project. By using Agile Methodologies, we are well-positioned to address, anticipate and adapt to such change. Antiquated methods of software development such as Waterfall are inefficient means to address changes efficiently because they lack productive communication. Agile changes the behavior of a development team. The technical practices stay the same, but the way in which team members interact with each other is paramount to the success of becoming truly Agile. Whereas older methods of development like Waterfall rely on requirements documentation, Agile sets clear guidelines that require team members to collaborate and interact. In essence, these interactions are Agile