Posts Tagged ‘planning’

Definition of done

August 26, 2008

When you’re starting out with a new team, or just wanting to review your existing process it’s always worth making sure all the team understand what “done” actually means.

Is a work item done when the code is complete on the developers local machine or is it when it’s been tested and deployed to your QA environment? For some of you, done might mean when fully shipped to live.

My team define done as

  • Feature from product backlog coded in entirety
  • Code reviewed by another member of the team
  • Functionality tested in QA (or System Test as we call it)
  • Functionality tested as part of regression testing in QA
Then, and only then will it move into the done swimming lane of our sprint board and be included in the build for the next release to production. How about yours?

Can you tell me why?

July 27, 2008

Failure to put the time aside to discuss requirements can leave gaps of understanding of what’s actually needed. The knock of trying to “save time” by not including this in your planning can be catastrophic to your product development and budget!

Making sure your development team has a clear understanding of what your client requirements will save time and hassle when you get to your planning and sprint stage.

To do this, meet with the business to discuss their new ideas and get involved. It might be there is already something on the site that could be modified to accommodate the new idea or you might need to suggest a meeting with other interested parties to discuss. 

If you’re lucky, the business will have a cost / benefit stage before going down the road of development. As I product manager I like to get involved here, before it’s too late. Knowing what’s in the pipeline and what’s most important to the business will assist your feature planning and flag any potential risks to other projects you’re currently involved in.

Recently I held a session for a home page redesign. We were lucky enough to have a full set of persona’s to work out user stories from. Each persona raised new questions on why the changes were required and helped us create a list of user stories to begin our planning with the development team. 

By meeting with the all the stake holders I got a clear understanding of the requirements (Commercial, Marketing, SEO & UCD)  which were easily translated back to the development team for further analysis. 

If you don’t know where you’re going, how will you know when you’re going to arrive?