Archive for the ‘agile’ 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 do it better?


Agile is not a silver bullet to low cost and do things better at all with the same team you always use for RUP or Waterfall project, or worst with a new inexperienced team, just because “Agile do it better!”.
I appreciate a metaphor that could be our starting point for the discussion:
“Waterfall is like determining where your child will go to college while he’s still in diapers: you hope for Harvard, you save money, lecture the kid on value of a good education but…”
“Agile is like reading age appropriate stories to your child, reading just ahead on childhood development, testing and adapting, rather than expecting and looking for expectation.”
Before you go on, I want to make it clear that if your project have to solve a well known problem, not likely to change with a well defined scope (maintenance is a common example), please stop reading… in this scenario selling or buying agile project for cost saving isn’t always a good idea: I’ll explain because Agile is about lower overall cost but lower overall cost isn’t doing things cheap!.

  • Agile addresses risk in concrete way in case the client really don’t know what he wants or needs until they’re in it (a classic statement is “If I can’t see I can’t decide what I want!”). Otherwise, if he knows his willing and he had the capability to express and communicate his requirements in appropriate way (I have still to meet such this client!), you can do it traditional way!
  • Agile doesn’t aim to be a low-cost alternative at all. In Agile the client pays for the risk reduction that an Agile team provides and, considering only an overall cost component of the project, the unit cost for an Agile project could be higher. But within that kind of project the client get as much ROI as their budget will allow over well-defined periods: shorten time-to-market, increase adaptability and reap greater ROI over the lifetime of a product. Earlyer opportunities to start getting ROI with the Agile ability to sell some critical subset of the features to a subset of your potential users providing a good value to some of your market even if the product lacks some features. Even if a project ends prematurely, the client has something of value.
    The benefits are about revenue, not costs. One more time: if the overall cost is our client only concern, Agile is not our silver bullet!
  • If a company doesn’t matter about quality and defect costs, it ignores a cost component of its project which sooner or later it will pay. In this scenario, one more time, Agile (which takes more effort/work to quality, testing and evolutionary design) will look more expensive on our costs spreadsheet.
    If you want code without automated tests you can do your project in half the time… do it traditional way! But what will cost later? (I hope you’ll never curse the missing of non-regression tests!)
    Or Even more, from a business perspective, I can plan and design everything now but what will be the cost of business/process unknowns and market changes later when I can’t handle it?
  • Early or late some projects are doomed to fail, no matter what method is used to develop them. Earlier you can measure your project success, earlier you can react appropriately and either turn things around or in the worst case scenario re-direct the remaining resources into something else that will hopefully provide ROI. The way Agile works tends to get feedback early and if something if something just isn’t going to work no matter what (technical problems or improvements, market changes, business model corrections).
  • Inexperienced team will be inexperienced team no matter the project methodology. Agile, with smaller iterations and frequent process review, allows an inexperienced team to learn and improve faster if well coached.

Before you will start to embrace Agile for your project, take some times to evaluate other components: customer relationship, contractual constraints, far-located teams, …
No one methodology is automatically best suited for all the project, product, customer and team. Find your own way!

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.