A story point trick

So, story points are used to judge the complexity and difficulty of a story in relation to other stories, right? Well, I've seen story pointing sessions where the stories all tend to be the same points (13 or so) or the story points are so controversial that a 1/2 point is added to one story and not another.

Here's a trick. After a few sprints, create a spreadsheet of story references, their points, and the sprint in which they were played. Sort the spreadsheet by point, sprint, then reference. Next time you go to a story pointing session hand out the list to the entire team and use this as a reference when someone trys to split hairs with a story. The point of the matter is to keep pointing consistent among the stories, not highly precise.

As time goes on, the team can strip stories from the spreadsheet that no longer seem like good representatives of that size.

This technique works great!

What's the best way to specify requirements?

Are user stories better than other types of requirements specification?

User stories are narrative texts that focus on the value a user gains from the system. The basic thing about a real user story is that it's a metaphor for the work being done, not a highly documented requirement. The intent is to enhance collaboration about the topic of the user story - in other words in agile development (good agile at least), the documentation is secondary to the collaboration.

We value people over process, remember? Any technique may be flawed, but it’s the individual and team that can make it work or fail . If someone is used to iterative approach I believe they can make the other use cases and user stories work. If someone is steeped in big requirements up front (BRUF) then they will bring that style to user stories and end up with traditional requirements that are termed stories. At the end of the day it’s the individual that’ll make a technique fail or succeed.

As agile coaches and authors, we stress people and the importance of people and the team, but all too often focus on techniques, not the intent of the techniques or the underlying values of the agile manifesto.

So are user stories the best way to document requirements? Yes, if and only if you can foster collaboration. If your writing user stories and not seeing collaboration, the user stories are not helping and you might as well write traditional requirements (or better yet start to emphasize collaboration).