As a recap from my previous post, I spoke about philosophy on “As a…I want to…so that…”, and today I will continue to describe some additional information my team likes to include in a story if we know there will be data entry.

Fields

When we find a user story describes some level of data entry, my team likes to reserve a section of the story body for recording the various fields relating to the user story. For example, consider the “Login” user story: “As a user, I want to login, so I can access my account.” The fields described in this story are Email and Password, which result in the following story format:

Login

As a user, I want to Login, so I can access my account.

Fields:

• Email*
• Password*

You will note the * next to the fields listed above. My team uses this to indicate required fields.

Working with new teams, a question that is often asked after explaining the * is how detailed should we go? Should we indicate whether a field should be a drop down, a special calendar drop down (if we’re entering dates), what format should we accept in a field, etc. My team leans towards including less information, using their best judgment, based on past experience. Perhaps this choice driven from our level of experience. Regardless of the reason, we have confidence our developers will use their best judgment in establishing some basic rules. Our end goal is to produce something quickly and get feedback, and we don’t let minute things such as the length of a field to bog us down from making a judgment. After all, changing the field length is a simple change.