Need a basic ‘Definition of Done’ – Here’s one ;)

Definition of Done

  1. All acceptance criteria has been met.
  2. All tests are passing.
  3. Code has been peer reviewed and refactored where necessary.
  4. Any technical debt has been recorded in a new story.
  5. New functionality is documented in the Wiki.
  6. Changes to the interface are documented in the IDL and REST documentation.
  7. Key decisions are documented in the Decision log.
  8. The build is ready to be deployed.
Advertisements

Project Documentation – How much is enough?

With Project documentation it is prudent to remember that less is often more. Consider who the documentation is for, why they need it and what they are going to use it for.

With those three pieces of information you can deliver good quality required reports that are useful to the individual.

Think about the type of document that you will use for your report. Word docs aren’t always the best. A graph or chart could show the required information more clearly and be more useful to the end-user.

The best way to achieve this is to scope the documentation that the project requires in the initial phase of the project. For each requested document ask for a user case. It is worth remembering that you may receive the answer:

“…because I said so…”

No matter who says this, dig deeper there must be a reason for each of the project documents.

You can always try defining and justifying project documentation using the ROI approach.  As a consultant they are paying for your time.  By having a user case for each of the project documents you can prove the value and the benefits in each case, this will ensure that the client is not paying for wasted time.

Results Focused Delivery – Keeping an eye on ROI

How do you deliver a whole list of product features?  There are two question that you should ask of the project:

What does the stakeholder think are the most important features?
What features benefit the business the most?

You will often find that the two sets of answers that you receive will not match up.  In many situations the key features for the stakeholders are those most important to them as an individual, not the most important to the business.  There may be certain things that they will have been tasked to deliver within the product that are linked to their yearly performance metrics and goals, so it is a fairly sure thing that they will push these heavily in order to reach their targets.

You on the other hand will have a scope that dictates the product backlog of business benefits that are required from the system and will need to deliver a mix of business benefits and stakeholder features.

How do you do this effectively?

Start to look at business benefits in terms of return on Investment (ROI) in order to create leverage,  you can do this through evidence based delivery.

Take an example of a software platform where a stakeholder requires a mobile application as an additional feature.  You have a target audience, your number of prospective downloads and the cost of developing the app.  If you discover the true cost of each download the ROI may not be at the level required by the business.  It therefore ceases to be an asset that adds benefit to the product.

If this principle of calculating fiscal value or business benefit is applied to the whole of the product backlog you can assign those items with the greatest ROI to the top of the list and give clear reasons for each in terms of value to the business.