Risk Context

Risk Management is a part of everyday life, crossing the street or even walking downstairs in the morning carries with it some risk factor.  A project is no different.  When projects were managed by default by using high overhead techniques such as PRINCE2, risk was an integral part of running a project; they were cataloged, monitored and actively mitigated through the use of logs and registers.  Many of us have since abandoned these heavy methods in favour of lighter approaches, such as Scrum or Kanban.  However, amid all of the confusion in the revolution, we appear to have thrown the baby out with the bath water.  Even now, risk is rarely included as an active element in our practice, and rarely done well.  I would propose a new method of managing risk, something lightweight that fits with our de facto practices, but with the rigour of the old guard.

What is Risk?

First, let’s define risk.  The ISO31000 standard defined risk as an uncertain event, which should it occur, will have an effect on the project meeting it’s objectives.  Notice the lack of connotation here, risk isn’t some inherently bad thing, it’s simply a degree of uncertainty.  The message is clear, we should be looking for, and actively managing, all forms of uncertainty.

Risk sits in the middle of cause and effect, some cause may trigger an effect, although we don’t know.

Risk Context

Continue reading

All relevant stakeholders should be present at this meeting, including owner, Scrum master, clients and developers.  For a Scrum overview, please see Agile Overview.  This guide is heavily influenced by Mike Cohn’s Agile Planning and Estimation.

Choosing Themes

At project initiation, the team will meet in order to determine the themes and goals of the project.  In determining these themes, many factors will need to be considered.  These themes will also need to be estimated and prioritised so that the development team knows what to build.  These initial themes will form the general functional requirements for the project and will be expanded upon later on, when more knowledge is gathered about exactly what needs to be done.  The owner will determine the themes, but the developers will aid in this choice.  Developers can help this decision by indicating the risk level or dependencies of each theme.  These themes are often written on Index cards and should be considered at a high level of abstraction, such as:

  • As a user, I require the ability to add new cars so that I can manage my growing stock.
  • As a user, I should be able to buy items using a credit card so that I can process my order quickly and securely.
  • As a user, I want the software to record my high scores so that I can try and beat other scores.

Note that there is no technical specifics here, these are simply general, high level features that the user requires for the product.

Continue reading