Archive for the ‘practices’ Category

Agile practices: User Story


Describes functionality that will be valuable to a user of a system and composed of three aspects:

  • Card: a written description of the story used for planning and as a reminder
  • Conversation: verbal conversations about the story that serve to flesh out the details of the story
  • Confirmation: tests that convey and document details and that can be used to determine when a story is complete


  • Indipendent: as much as possible (to prevent planning and estimation  problems due to story dependencies);
  • Negotiable: they are remainders for the team-customer conversation, details are written as notes (1 or 2 phrase). The challenge comes in learning to include just enough detail, other discussions become test (written on the rear of the card: “if I haven’t an account the application invite me to subscribe the service”);
  • Valuable: give value to the user, no use of technical details;
  • Estimable: it’s important the team is able to estimate. Common problems which block estimation: domain knowledge problem (solution: talk to product owner!), lack of technical knowledge (solution: realize a proof of concept), the story is too big (solution: find smaller constituent stories);
  • Small: too big or small stories are not suitable for planning (the burndown chart lose value and this prevent from project day-by-day status evaluation);
  • Testable: successfully passing its test prove that a story has been successfully developed and Done!.

Classic story statement template:

As a <role> I want to <what> So that <why>

Use Case versus User Story:

Use Case: Describes how an Actor interacts with the system to achieve a Goal
Focus is on user and validation – Tells a “complete story” with main flow and alternative flow (in case of error or different user behaviors).
User Story: A bite-size bit of functionality that has business value and can be developed in a few days.
Focus is on developer and production – Part of a “complete story”.


  • Try to write independent stories to avoid story dependencies in priority evaluation;
  • Split stories when: developers say “too large”, cannot fit in one iteration, needs too much to do;
  • User story represents a team activity, so it could be of different kind: standard (standard user story), constraint (abstract non-functional story as “each password should be cipher on the database”), bug (if you consider the bugfixing in your development activity), technical (other time-consuming tasks, for example “install a new profiling tools”);
  • Cards are small to reduce verbosity, use the rear to best capture stories in the form of acceptance tests (“try with alphanumeric input”, “try miss name field”, …);
  • Check the story doesn’t contain technical jergon;
  • If you need to release an excluded story inside the current iteration, you can: change priority, split a big story and exclude its less-priority part, reduce the scope of other stories.

Non-functional requirements:

We can consider some of these as standalone stories (password expiration, …) but others have to be written in a Non Functional Requirements Guideline document (password encryption on database, general validation rules, …) shared with the team. However we must try to remember and express some of these as Acceptance Test during the discussion.

Documentation tasks:

Effort for write/update documents with a relationship with a specific user story (e.g. functional document, …) must be included in the story estimation.

Effort for cross-stories documents (installation guides, …) must be considered in a separate story (e.g. a “As Operation I want an installation guide so that I can install”) and have specific estimation.


Agile practices: Sprint review meeting (Demo!)


Leaded by the Team Members and attended by Product Owner, anyone can join (usually the customer make invitations).


  • Business level demo, if the software has no UI encourage the team to create it;
  • No use of long ppt presentations and let the audience try;
  • Use standard, shared and known tools (wiki, team room, …);
  • Begin with a clear presentation of goal;
  • Be informative (e.g. show graph to explain performance improvements, etc.);
  • Bringing food to a meeting (such as biscuits) is a good way to relax people and make the meeting friendlier, a nice way to break up a long meeting or to encourage to arrive on time;
  • If possible, use informal or funny elements (pic, example, …) to get an entertaining and amusing atmosphere.

Finalize the demo:

  • On the last day of iteration finalize demo (everyone have to play a part!):
  • Clarify which stories are complete and ready to demo;
  • Decide on a running order for presenting the stories;
  • Agree who will be presenting which stories;
  • Schedule the activities to finalize and organize a run-through to rehearse the demo (don’t undervalue preparation!);
  • Reconnaissance of the demo room: network connectivity, proxy, browser version, projector, whiteboard, …;
  • Technical check of the demo test environment: integration status, software configuration, build version,… .

Demo Agenda:

  • Introduction for the customer (overview of goal and user stories chosen) using standard team’s tools (wiki, …);
  • Demonstrate stories and ensure that positive and negative feedbacks are captured (use cards or other sheets, whiteboard can distract the audience);
  • Review the main points with the group to check none has been missed, these can be used for next iterations;
  • Celebrate!

Other references: It’s all about marketing.

Agile Practices: Estimation


Agile time management depends on two variables:

  • Team Velocity, i.e. number of story point for iteration
  • Stories Size, i.e. the dimension associated with a story

There are different way to evaluate stories size, here some suggestions.

Approach 1 – Ideal time:

During the planning meeting estimate stories with ideal days of work, i.e. a day without any interruptions whatsoever, no telephone, no meeting, …
Velocity comes from historical series of iterations velocity, but for initial iteration we can define Initial Velocity as:

(Number of team members/Load factor) * Sprint days

Load factor is a number that you can use to adjust the ideal day, i.e. the impact of distractions on a team’s performance.


  • Easier to explain outside the team
  • Easier to estimate at first
  • Make the team more comfortable

Approach 2 – Story Point:

If you don’t have previous estimated user stories, ask the team members to select one story which they think is about average effort to implement.
Give the value of 5 story points to this story and estimate all the other stories relative to the selected story.
Break down the selected story to estimate its parts in hours and define the value of initial story point in hours.
Estimated initial velocity is:

(Sprint hours/hours per Story Point)*Focus factor

with focus factor in percentage.


  • Faster
  • Do not decay
  • Pure measure of size

A good starting compromise (to define initial velocity):

For your first iteration define “1 story point = 1 ideal day” help team to get started and gradually convert team to thinking in unit-less story points (“this story is like the story …”) stopping talking about how long it will take.