User stories for production support (part 1: FAB)

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)”

Elaborating user stories: what about architecture?

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?”

Elaborating user stories by breaking them into tasks

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”

Using MoSCoW to prioritize ideas

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”