Agile Analysis and Designs

User stories are short, simple description of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system.

They typically follow a simple template:

As a , I want so that . User stories are often written on index cards or sticky notes, stored in a shoe box, and arranged on walls or tables to facilitate planning and discussion. As such, they strongly shift the focus from writing about features to discussing them. In fact, these discussions are more important than whatever text is written. An Epic is a large story that cannot be completed in a single sprint.

For example, you may set yourself a goal for ranking high for a particular term. This can be rewritten as a user story. A Theme is a group of user stories that share a common attribute, and for convenience they are grouped together. The individual user stories, however, can each be accomplished in a single sprint.

A typical example of user story would be:

As a user, I can withdraw money from ATM. Because an epic is generally too large for an agile team to complete in one iteration, it is split into multiple smaller user stories before it is worked on. As a power user, I can withdraw money from ATM provided machine has cash. As a user, I can withdraw money from ATM provided I have credit available.

So, detail can be added to user stories in two ways:

• By splitting a user story into multiple, smaller user stories.

• By adding “conditions of satisfaction”.

• When a relatively large story is split into multiple, smaller agile user stories, it is natural to assume that detail has been added.

Story Maps

Story mapping consists of ordering user stories along two independent dimensions. It provides more structured approach to release planning, iteration planning's. The "map" arranges user activities along the horizontal axis in rough order of priority (or "the order in which you would describe activities to explain the behavior of the system"). Down the vertical axis, it represents increasing sophistication of the implementation. Given a story map so arranged, the first horizontal row represents a "walking skeleton", a bare bones but usable version of the product. Working through successive rows fleshes out the product with additional functionality. First we group the stories by application/theme/functionality and create the grid. Horizontally, we can find the title for each grouped functionality; vertically, the main stories/issues related to each group. The functionalities are prioritized from left (more important) to right (less important). Each group will then have the stories prioritized again vertically. Once the stories are organized, we can start slicing the list

Story Mapping enables both a top-down and bottom-up perspective of the system to emerge. It facilitates understanding of the system from the users' perspective. It also lends itself to iterative delivery in that prioritization and grouping of Features into Releases/Minimum Marketable Features is supported. We can use different Colours in different ways.

For example, in case we can use them to identify the main objectives of each sprint. But there is no straight rule; we can use colours for many different purposes.

For example, use different colours:

• Depending on the estimation (or if they are not estimated yet)

• To identify complexity

• To split between technical and business

• Even to identify new functionality added in a second instance

• Personas

• User experience is a major factor in project outcomes - the team crafts detailed, synthetic biographies of fictitious users of the future product: these are called "personas”

• Personas are concise and visual; a common layout is a single page including a photograph (from stock shots or magazine cut-outs), a name and social or professional details: "Amanda Jones, 34, press officer at a major food retailing organization, etc.“.

• Software product is generally intended for use by more than one category of person, with potentially different preferences and expectations of the product, the team creates one persona for each category it deems important to serve well.

• Personas provide designers and developers with an anchor for justifying design choices: rather than appeal to vague notions of "ease of use", they suggest questions of "what Amanda would do" or "whether Bob will understand" a given feature, interaction, or visual cues

Progressive Elaboration

“Progressive elaboration, is defined by PMBOK as continuously improving and detailing a plan as more detailed and specific information and more accurate estimates become available as the project progresses, and thereby producing more accurate and complete plans that result from the successive iterations of the planning process”.

In other words, we use the best practices of project management to uncover the requirements, plan a project that meets those requirements and do regular realignment as information is clarified or changed. We will never know everything about a project at the beginning and yet we must start working towards the final outcomes. We build iteration and flexibility into the project plan to accommodate the changes and refinements that we know will occur. Once the baseline documents are reviewed and approved, we use change management to update our project plan.

Here are three common times when stories will be worked on during an agile project:

Inception

You often create a stack of user stories during Inception as part of your requirements envisioning activities to identify the scope of your system. Construction (Planning & Realization)- During construction iterations you will identify, plan new stories, split existing stories when you realize that they're too large to be implemented in single iteration. Reprioritize existing stories, or remove stories that are no longer considered to be in scope.

The point is that your stories evolve over time just like other types of requirements models evolve. Furthermore, enhancement requests may be identified by your support staff during the production phase and then forwarded to a development team as they are working on an upcoming release. These enhancement requests are effectively new stories (albeit in a different format).

Transition

Sometimes new stories will be identified during the Transition phase, although this isn't very common as the focus of release is on hardening the system and not on new functionality. But it does happen, and these stories would be prioritized and placed on the stack in priority order just as you normally would.

The 3 C’s of User Stories – Principles

User stories need to be confirmed with the 3C guidelines below, suggested by Ron Jeffries:

Card: User stories are traditionally written on index cards or sticky notes, in short form. User narratives further explain these cards. Thus the main intention is to describe the user story in short form to allow common understanding of the user need among all stakeholders.

Conversation: User stories shift the focus from writing about features to discussing them. In fact, these discussions are more important than whatever text is written.

Confirmation: Acceptance tests confirm that the story was delivered correctly. Let us take an example.

User story title: Customer withdraws cash. As a customer, I want to withdraw cash from an ATM. So that I don't have to wait in line at the bank.

Acceptance Criterion 1:

Given that the account is creditworthy and the card is valid and the dispenser contains cash, when the customer requests the cash then ensure the account is debited and ensure cash is dispensed and ensure the card is returned. Invest Criteria of User Stories

What really makes for a good story though?

There has to be more to it than the use of good grammar and the avoidance of tautology.

Well, there are indeed some additional considerations, and they are referred to as the User Story INVEST criteria:

Independent: User Stories should not overlap in terms of the value they deliver.

Negotiable: It should be possible to debate and change User Stories, and to trade them in and out of scope.

Valuable: Every User Story must deliver stakeholder benefit.

Estimable: It should be possible to anticipate how much effort a User Story will require for implementation.

Small: It is better to work on multiple small pieces of work than a larger one, since progress is more easily ascertained and at least some value can potentially be delivered earlier.

Testable: It should be possible to confirm the successful completion of a User Story by objective means.

Wireframes

Wireframes outline what goes where for a set of UI screens. Wireframes typically outline the components for a screen, together with any associated behaviours, such as what happens when a button is click and where a hyperlink should go. They don’t show exactly how a screen will appear, only how it will be composed and how it will behave.

Wireframe is:

• A prototyping tool

• A low-fidelity prototype

• Non-graphical artifact showing the skeleton of the screen, representing its structure and basic layout

• Used as a communication tool serving as an element of conversation and confirmation of “agile” user stories

They are typically free from graphic design features like colours, typography or actual images and try to answer the following questions instead:

• What elements will be displayed in the UI?

• How will the elements be organized?

• How will the interface work?

• How does the user interact with the application / website?