Writing Good User Stories - The key to everything in Agile
Applying Principles from The Agile Samurai: How Agile Masters Deliver Great Software by Jonathan Rasmusson
One of the things I have learned as I have been involved in Agile development is how important it is to write good user stories. Learning how to do this is not easy when coming from a traditional development environment. Mr. Rasmusson's book The Agile Samurai provides a good summary of the difference between user stories vs. specifications & requirements documents.
| User Stories | Specifications & Requirements Documents |
|---|---|
| Lean, accurate, just in time | Heavy, inaccurate, out-of-date |
| Encourage face-to-face communication |
Encourage guesswork (false assumptions); "Throw it over the wall" |
| Simplified planning | Complex planning |
| Never out-of-date | Always out-of-date |
| Based on latest learnings | Based on little or no learnings; or old learnings |
| Enable real-time feedback | Real time feedback discouraged |
| Avoid false sense of accuracy | Promotes false sense of accuracy |
| Allow for team-based collaboration and innovation | Discourage open collaboration and innovation |
| Cheap, fast, easy to create | Expensive, time consuming, hard to create |
Anyone who has worked in a traditional environment is going to recognize the reality of the "Specifications & Requirements Documents" approach. Here is an example of a user story that has been done by one of the teams where I work.
Calculate US Taxes – Sub – Self Adjustments to Soc Sec & Medicare
User Story Description: (1262)
As a Payroll engine I need to make occasional adjustments when calculating Social Security & Medicare taxes to ensure a payee's YTD amount paid is always accurate.
Notes:
- Applies only to the US
- Provides the engine with the ability to self-correct
- Engine checks payee's and client's (ER) soc sec and medicare taxes to ensure that the amounts are correct. If they are not, the Engine should automatically correct the amounts by adjusting the amount withheld.
- The system should consider YTD info and applies the correction to the current check
- Need to check whether BSI can do this (Yes, verified. 6/2 CSH)
Assume:
Use BSI to get the annual limit
Testing Considerations:
To trigger this situation: Historical data for these 2 taxes on a payee will need to be adjusted in a way that makes the total taxes not = to the applicable rate times wages basis.Acceptance criteria:
FICA Adjustments - YTD Soc Sec Taxes are adjusted as necessary per payroll run so they = (4.2% X FICA Wages).
FICA Adjustments - YTD Medicare Taxes are adjusted as necessary per payroll run so they = (1.45% X FICAWages).
Employer version of each tax will also be adjusted as appropriate.
Adjustments are reported in payroll run audit messages.
Scenarios:
Scenario 1: Social Security Taxes adjustments
Given payee YTD Soc Sec Taxes are out of synch with YTD Wages Basis (EE = 4.2% X FICA Wages, ER = 6.2% X FICA Wages)
When BSI Tax Calculator is called
Then the current tax amount assessed will be adjusted by the shortage/overage so that the total YTD amount taken matches the YTD Wages for such.
Scenario 2: Medicare Taxes adjustments
Given payee YTD Medicare Taxes are out of synch with YTD Wages Basis (1.45% X FICA Wages)
When BSI Tax Calculator is called
Then the current tax amount assessed will be adjusted by the shortage/overage so that the total YTD amount taken matches the YTD Wages for such.
So key features that we have found which help the entire team are the Acceptance criteria and Testing Scenarios. Since our Business Analyst write the user stories and work closely with the Product Owners they have a good understanding about what is required for the story to be acceptable and the scenarios in which the user story will be used. But every member of the team can make suggestions to add to the User Story as we discover things about the story to make it more complete.
Without a good user story it is almost impossible to meet the other goals in Agile development. In my experience this is the key to Agile development.