I think risk management is really cool … and certainly more fun than the alternative.
Unfortunately many people find the traditional approaches to analysing risks dry and un-innovative; which is a problem because identification and analysis of risk is actually a creative process.
So here are a couple of “unusual” approaches that might work for your team. Continue reading “Unusual risk analysis techniques”
I have recently been talking about elaborating stories in agile projects and the topic of architecture came up.
As as result Philippe Kruchten sent me a link to the “Hard Choices” game – a game that can be run in workshops and training courses to demonstrate the difficult tradeoffs involved in architecture on projects.
http://www.sei.cmu.edu/architecture/tools/hardchoices/
Continue reading “The Hard Choices game – teaching architecture to agile teams”
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?”
Comparison tables involve listing stories and then comparing the components or factors relevant to each story. Generally speaking a comparison table is created as follow:
Continue reading “Elaborating user stories by using comparison tables”
Abstract to concrete is a term I am going to use to describe the idea of elaborating stories by:
Continue reading “Elaborating user stories by using abstract to concrete approaches”
Rather than breaking the story into tasks or acceptance tests, some teams simply break stories into multiple, smaller stories until they are small enough to build from.
Continue reading “Elaborating user stories by using technical stories”
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”
Elaborating stories using acceptance tests involves defining the criteria for stories before turning them into code. This is the approach we often teach in agile courses.
Continue reading “Elaborating user stories by using acceptance tests”
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.
