Skip to content →

Month: May 2012

Designers Vs Developers

I have a great appreciation for design and understand its importance in the online & offline world, however on the last few projects I have worked on I have found a great deal of friction between the designers and developers. This has often been born from the fact that the designers work in Photoshop, and have therefore had no real restrictions to what they can deliver, yet the developers have had to implement whatever came through from design irrespective of how hard, or even if it was possible.

The success of Twitter’s Bootstrap and even the iPhone can be awarded to the specific UI guidlines set out by Apple, and it proves that people can build incredible stuff quickly and cost efficiently when they dont have to worry about design.

So, to that end I asked our front end developer to document our UI framework ala Bootsrap style, so that we could move forward from pixel pushing and build from using UI building blocks. Their response was this the Tesco Entertainment UI style guide which I think is a fantastic result, and means that our developers can deliver more functionality faster and cheaper. Well done guys. Credits to Steve Uprichard & Gareth Slinn

Leave a Comment

The Life of a Story

A colleague of mine Derrick Malone put together some instructions for how to manage User Stories during our development cycles. This was published on our internal wiki, but I thought that it was worth publishing to the wider audience due to its excellent, concise delivery. So with Derrick’s permission here it is:

Discovery

  • Business rep gathers ideas from around the business (Tesco in this case) and raises with BA
  • BA captures ideas in Pivotal Tracker Icebox, providing what info he can and also raising obvious questions in ‘Descriptions’
  • Tasks can be used here to describe next steps to be undertaken to aid understanding
  • BA and business work together to understand who the story benefits, what is to be developed and why a postive outcome is to be expected.

Planning

  • When it is better understood the initial story is split into sensibly sized stories, each of which can be released independently to deliver value.
  • The stories are ordered sensibly by the BA and prioritised by the business to deliver most value (and learning) first
  • All dependencies (eg designs, platform work, unanswered questions) are identified and captured in the user stories
  • Stories are presented to the development team for their input and estimation.
  • story is estimated if it is suffiently understood by the dev team
  • There are four acceptable estimates:
    0 – no dev work required
    1 – a small amount of dev work required
    2 – a medium amount of dev work required
    3 – a large amount of dev work required
  • story should take no longer than a week to complete. If developers think it it exceeds a week the story should be broken up into smaller stories that each delivery value.
  • When fully understood and estimated a story can be prioritised into the Pivotal Tracker Backlog

Delivery

  • When available a developer picks up the highest priority story available (the story nearest the top of the Current column).
  • The developer should review the acceptance criteria, hit the Start button in Pivotal Tracker and discuss the story with the BA and a tester.
  • In the Tasks field the developer should document the steps he will pursue to meet the acceptance criteria and deliver the user story.
  • When the developer has completed the work necessary to satisfy the acceptance crieria he demonstrates the feature to both a tester and the BA.
  • If all agree that the story can now be passed on to a tester the developer hits Finish on the story and moves on to a new story.
  • A tester takes the highest priority story marked with ‘Deliver’.
  • The tester hits the Deliver button to own the story.
  • When a tester is satisfied that the story is done he should demo to the Business and/or BA and, if they agree, he can hit ‘Accept’
  • If a tester finds problems with the story meeting the acceptance critera – or other problems with the story implemenation – he raises issues in the Activity field and hits the Reject button.
  • This changes the status of the story back to ‘Restart’
  • A developer should pick up the highest un-assigned story in a Restart state.
  • All Accepted stories are ready to be released and, ideally, should be released at the earliest opportunity.

Review

  • Stories should be reviewed against their stated goals after they have been released (this yet to be fully defined).

Iterate

  • Improvements should be developed from learnings gathered during planning, development and review.

This process is a little specific as we use the excellent Pivotal Tracker as our backlog management tool, however the process could be delivered using any Agile project management tool.

Leave a Comment