Simple User Stories Framework

A simple framework for writing User Stories is as follows:

  • As a <ROLE> I want <SOMETHING> so that <OUTCOME>

<ROLE> relates to the visitor and can describe the relationship between the visitor and the application, examples can include:

  • New visitor
  • Returning visitor
  • Subscriber
  • New Customer
  • Existing Customer
  • Lapsed customer

<SOMETHING> describes a key task that the user will want to complete to help articulate a requirement for the site

<OUTCOME> explains what will be a result of the action.

An example, of a user story could be:

As a customer I want to change an existing open order (i.e. size, amount) so that I can ensure my order is actually what I want

The 4 levels of Plan

Outline Plan – Feasibility

At the end of Feasibility there is still mush uncertainty

To move on, a detailed plan is needed for foundations

Also need to provide approximate size and duration of oerall project

  • Based on what at this point – can only be educated and uessed

Typical Outline Plan

Plans next few weeks (Foundations) in details

  • Includes Timescale, deliverables and resources
  • Provides an outline for the first increment
  • List planned dates for deployment of later increments
    • Detail not normally provided here for later increments

Delivery Plan

At the end of Foundations the requirements are now better understood

  • More detail, better sizing and MOSCOW applied

Now possible to create a Delivery Plan, focused on 2 areas

  • Scheduling Work and Defining the approach

Scheduling work

  • A plan for deployment of current Increment and agreed schedule of timeboxes leading up to that deployment
  • As each Increment is completed, new schedule of timeboxes is created for the next Increment

Defining the approach:

  • Delivery plan describes overall structure and approach to be adopted when working in Development timeboxes
  • Confirms exact resources for the project
  • Outlines number and likely length of Development Timeboxes
  • Provide information on the probable focus for Timeboxes and strategy for developing solution

Delivery Plan also includes an outline of Projects Increments

  • Expands later into Deployment Plan

Delivery Plan does not provide low-level plans for TImeboxes

  • This is done by team at the start of each Timebox

Development Plan

Once in development, enough information is available to crate detail of Deployment Plan

  • Includes everything needed to move the Solution (or partial solution) into the operational environment
  • May include Business Deplyment plans (such as business process change information and training)
  • May include benefits realisation plan

Timebox Plan

Lowest level of plans

For the next timebox, Solution Development Team should agree and record:

  • What they will be working on in the next few weeks
  • Teams MOSCOW priorities

…and Predict….

  • What will be delivered (Must Haves)
  • What is highly likely to be achieved (Should Haves)
  • What may or may not get done in this Timebox (Could Haves)

Estimating and Measuring in Agile Projects

Agile estimates include contingency to cover the risk of the unknown

  • Contingency managed in scope of work and by applying MOSCOW

Close relationship between detail of requirements and accuracy of estimates

  • As the project moves forward, more is known and the less assumptions are made (as well as more requirement being identified) making estimates more accurate

Estimates only as precise and accurate as necessary for their purpose at any given point

  • Estimates vary in accuracy and serve different purposes

Estimating in Feasability & Foundations

  • Feasibility estimates aid planning and support initial business case
  • Foundations estimates refine Feasibility estimates, based on deeper knowledge
    • Allows business case to be revised
    • Allows delivery plans to be created

Estimating in Exploration / Engineering

  • Exploration/Engineering estimates based on what happened in previous Timeboxes
    • Allows team to define what will be delivering in coming timebox
    • Allows team to re-validate estimate for whole project

Estimate revalidated throughout project

  • As understanding deepens
  • As team actual rate progress (velocity) is proven

Style of estimating (and therefore accuracy) varies

  • Feasibility & Foundations
  • Top Down estimate (broad brush, allow for uncertainty)
  • Bottom up – more precise, based on work breakdown

Requirement Planning Throughout Agile Project Management

Prioritised Requirements List

  • Requirements driven by Business Roles (Visionary, Ambassador, Advisors)
  • Details increase throughout lifecycle

Feasibility

  • High level requirements define main objectives of the project
  • Small number of highlevel statements through User Stories
    • User Stories
    • As a <ROLE> I want <SOMETHING> so that <OUTCOME>
    • E.g. As a customer I want to change an existing open order (i.e. size, amount) so that I can ensure my order is actually what I want

Foundations

  • High level requirements broken down into more detail
  • Good requirements define what is needed

Solution Development Timeboxes (Exploration & Engineering)

  • Requirements investigation in full detail
  • Focus in a small subset of the PRL within the Timebox

Requirement Planning Throughout Agile Project Management

Business Analyst role is key in identifying requirements:

Responsible for:

  • Ensuring clarity and completeness of requirements – by developing PRL
  • Ensuring business needs properly analysed and reflected in guidance for team to develop solution

Role includes:

  • Facilitates communication between business and technical roles
  • Helps business think through the full implications of their ideas
  • Close working relationship between Business Analyst, Ambassador, Tester

Has skills and techniques to help identify:

  • Dependencies, overlaps and conflicts between requirements
  • Effect project level requirements on corporate objectives & direction

Managing Agile Risk Management

Agile risk management us similar to traditional approaches

  1. Identify Risk
  2. Assess Risk Severity
  • Impact
  • Proximity

3. Plan Counter Measures

  • Fall Back Plan
  • Avoid Risk
  • Accept Risk
  • Reduce Risk
  • Transfer Risk
  • Share Risk

Risks that are particular to Agile include:

  • Not complying with Principles
  • Non-availability of Business roles
  • Having detailed specification up front
  • Expecting 100% solution
  • Swapping resources in and out

Top Tips

  • Project Approach Questionnaire helps to identify risks
  • Monitor adherence to principles
  • Ensure whole team is aware of the risks
  • At Timebox Kick-off, highlight risks relevant to this Timebox

Daily Stand-ups

Happens everyday!

  • Ideally whole solution team participate
  • Business Ambassador should attend too – even if dialling in
  • Wider stakeholders are welcome to attend and listen but not to participate

Opportunity to understand daily progress against timebox objectives

Each team member says:

  • What they have been doing since the last stand-up
  • What they will be doing between now and the next stand-up
  • Any problems, risks or issues they are encountering that are slowing progress

Short and focused

  • Normally no longer than 15 minutes
  • 2 mins per team member + 2 minutes

MoSCoW Prioritisation Table

MOSCOW Prioritisation Table

Must haves = “Deliver this or we cancel the project”

  • Project Manager or Business Analyst may challenge less obvious Must Haves
  • Business Visionary / Ambassador have the final say

The Business Sponsor perspective:

  • Sponsor expects delivery of all Must Haves
  • Typically delivery of most / all Should Haves

In terms of delivery:

Must Haves = Worste case scenario

Must Haves & Should Haves = Expected Scenario

Must, Should & Could Haves = Best case scenario

Agile’s 6 key techniques (Facilitated Workshops & Modeling)

Agile has 6 key techniques to help deliver successful projects.
  1. Facilitated Workshops
  2. Modelling
  3. MoSCow
  4. Timeboxing
  5. Iterative Development
  6. Daily Stand-ups

Facilitated Workshops

A structured approach to ensure that a group of people can reach a predetermined objective in a compressed timeframe, supported by an impartial facilitator.

Enables principle including:

  • Rich communication
  • Collaborative working
  • Clear continuous communication

High quality team decisions in short time-scales

High level of buy-in and ownership, achieving consensus

Used throughout lifecycle

Need to be planned in (and budgeted for)

Modelling

Solution Development Team use models to improve communication.

Modeling can be used throughout lifecycle

Use and formality dependent on nature of project and teams skills

This is an example of model to demonstrate the Agile technique.

Agile Modeling Example