Let me be clear. Software projects are predictably unpredictable. You cannot solve all the problems in the project plan. It’s good if we can schedule good ideas but people don’t think like this way. People solve problems in unexpected ways. This is where good ideas come from. Many are called “Ahaa Thoughts”.
Explaining things are easy. Documenting it is the hardest part, not only that, many devs hate this part, in a software development process. We could only interpret around 50% of "Ahaa Thoughts" into "words".
Writing user stories is not a hard task. Once you master it you can say:
"Documentation in Development processes was my Unicorn, and now it is my bitch"
Or
"Writing user stories was my Unicorn, and now it is my bitch"
As a good citizen, a Business Analyst or a Product Owner could use a template/standard. I use something like this:
User Story
| Name: | Customer List |
| As a: | User |
| I want: | Interactive Customer List |
| So that: | I can change the details of my customer |
| Size: | XS, S, M, L, XL |
This user story comes from my Product Backlog List. It is a White Note on my wall. Things I can do about this story are called Story Points, that explains further about the story. A story point is a Yellow Note on my White Note. I write it like this:
Acceptance Criteria/Story Points
| Name: | Delete an address |
| Given: | The customer is in an editable state |
| When: | The remove address button is pressed |
| Then: | The address will be removed from the list |
| And: | The change will persist after a refresh |
| Name: | Add an address |
| When: | The application is loaded |
| Then: | A list containing customer addresses will be displayed |
| And: | The name of each customer will be displayed with an image next to it |
To reduce the number of documents that we have to maintain in a development process, I use these User Stories and Acceptance Criteria for Testing. A Bugs is reported under a White Note or a specific Yellow Note, if not, a separate Defects Backlog List (parallel to my Product Backlog List).
For more readings;
Beyond Functional Requirements On Agile Projects by Scott W. Ambler
Complex Requirements On an Agile Project by Scott W. Ambler
Introduction to User Stories by Ambysoft
User Interface Prototypes by Ambysoft
2 comments:
Interesting! How do you add the none functional requirements in to the backlog?
Hi Ano - Sorry about the delayed response. I do not have a perfect answer for your query.
Typically, most NFRs are shared across many user stories. For instance, Performance, Security, Scalability, Supportability, Portability etc.
Now, a very common approach is to identify these NFRs as Constraints/Confirmations and add into AC/SP section when needed. Problem here is that you might end up with huge User Stories in mid-sprints.
The easiest option is to write them as User Stories, share them across Other User Stories and Story Points, perhaps list them in the Scrum Board.
However, when you bring these Constraints/Confirmations into your User Stories, it will be difficult to estimate and even to draw the line for Definition of Done.
MORE: I have updated the post, I suggest you read articles linked in the post.
Post a Comment