User stories are a great way to focus your requirements around the real needs of your users:
As a user I want to report on the number of users who read articles on my blog so I can see whether a topic is popular or not.
This approach can work really well for a production support team, but sometimes the users are listing issues or bugs, which don’t naturally follow the format. For example:
The current report is two slow, it needs to run in less than 30 seconds
Can I have the date modified to use Sydney time in Australia rather than GMT
The report sometimes crashes when I run it
Continue reading “User stories for production support (part 1: FAB)”
Some people worry that in our rush to become more agile we might be leaving good architecture behind. So I often reassure with the following statement:
Don’t worry – There is no doubt that the system’s architecture will emerge from what we are doing. The only question is whether it will be the architecture we want.
Continue reading “Elaborating user stories: what about architecture?”
In some teams, the iteration or sprint begins with the team discussing each story and breaking it down into the specific tasks that each team member will need to perform in order to complete the story. The team then track tasks on their story wall rather than complete stories.
Continue reading “Elaborating user stories by breaking them into tasks”
There are many approaches that work well when elaborating stories and the team should decide on the approach that works best for them.
Continue reading “An index to some approaches for elaborating stories”
I have been on a lot of projects in my time and I used to prioritise ideas or requirements as “high”, “medium” or “low” importance.
If people classified their requirement as low,however, we would record the requirement in a long list, thank them for their idea and then never talk about it again. If they classified it as medium then we promised get to it in “phase 2”, which meant after we ran out of money.
People learned over time to classify all of their requirements as high priority so we started adding new classifications like critical or super ultra high, which didn’t help at all.
Continue reading “Using MoSCoW to prioritize ideas”