There are many programming methodologies teams adopt.
One of them is extreme programming.
In this article, we’ll look at user stories and how they’re used in extreme programming.
User Stories
User stories are the foundation of extreme programming.
They are descriptions of small features that can be fit on a card.
A project would have many of these and they would be implemented one by one.
The description in these stories would all be from the user’s perspective.
Description of a User Story
A user story has a description.
An example of a user story would be:
‘As a user, I can save employee data by entering the data in a form’.
It’s simple and to the point.
However, we can add more details as well.
They can include things like specific cases and handling failure cases.
For example, we can write:
‘We must be able to enter North American phone numbers’.
This way, we won’t forget about these specific details when we’re implementing the story.
We should be able to implement whatever is in a story in a week or less.
With what’s written, we should get a picture of how we implement it.
Stories and Conversation
User stories are made up of 2 components.
There’s the written document.
We just write the description of the story in card or a virtual version of it.
Then there’s the 2nd component, which is much more important, which is the conversations that take place between the customer and the programmers over the life of the story.
We may want additional clarification or talk about things that we didn’t foresee before implementing the story.
Each story is carried through the project.
It servers as a token for planning and implementing whatever it requests.
The programmer needs to be able to estimate how difficult each story is.
The estimate should be in days or weeks of effort.
However, it can vary from project to project.
The best way to start is to write a few stories and ask programmers if they’re the right size or detail.
Programmers and Stories
Ideally, programmers don’t write stories.
We want all stories to belong to the customers.
Stories are all about expressing what customers want.
Therefore, the programmer should keep our hands off of them.
If the customer doesn’t know to write stories, programmers can guide them through the process.
How Many Stories?
The number of stories depends on the complexity of the system.
If a system is more complex, then we need more stories.
A simpler system will need fewer.
There should be at least one story for every major feature in the system.
We’ll probably need at least one story per programmer per month.
More is better.
Therefore, if we have 20 programmers working for 6 months, there would be 120 to 240 stories in the project.
Story Size
A story should encompass a week or 2 of programming time.
The customer can scope the work based on this.
Therefore, we can break stories down to smaller ones if they take longer than that.
Stories often have a more important part and a less important part.
We can split stories into to 2 based on that.
Some stories would be too small.
In that case, we can combine some of them into bigger ones.
Not Having All the Stories
We probably don’t have the stories outlined.
But this is fine because we keep the feedback from the customer as we do the project.
The planning is iterative and ongoing so we don’t have to worry about lacking stories.
Acceptance Tests
Tests are important in any system si that we can find out whether it works or not.
We should create tests as soon as possible so that we can test our system.
If we don’t, then it’ll lead to pain later on.
We definitely got to test before we ship.
Putting off overall testing until release if probably not a good idea.
If we fall behind, then testing time will be decreased.
Programmers forget what they did, so we should have tested as soon as we can.
If we test now, then we find defects now and fix them earlier.
If we find issues later, then we probably forgot what we did from earlier, so we would have to dig up what we did from memory and investigation, which may take a long time.
Conclusion
We should have customers write user stories.
This way, they can express what they want.
User stories have a written part and a conversation part. It’s important that we communicate.
Acceptance tests should be done earlier so that can fix defects earlier.
