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.

Story Points – How? Why?

Scrum tells us that it doesn’t matter what a story point is, only that it exists in some way.  Try explaining that to your stakeholders and see how long you last 🙂

Every stakeholder and product owner wants to know two things… “How much will it cost?” and “How long will it take..?” and no amount of wriggling will get you off the hook.

So for this you need to know a couple of things:
Total # of Story Points

How big is a story point? And how do I know what the velocity is?

Think about something non technical, like digging dirt out of the garden…It’s an example that has been used time and time again I’m not sure who came up with it first but it works so well

If I was to move 100 kg of dirt at 10 kg per hour  it would take me 10 hours.

So that would equate to:

100 Story Points (100kg of dirt) / 10 Story Points per Sprint (Moving 10kg per hour) = 10 Sprints.

Therefore if we want to answer how long will it take to develop a particular software product, we:

Add up the story points, divide by the velocity, and that gives us the time.

In order to do this we will need to create a reference story for all of the other story points to be compared against.  So how do we establish our reference story? And how do we know what velocity is?

In a Scrum environment, estimates are supposed to be done by the whole team, those who will actually perform the work.  So the team defines what a story point is.

The suggested way of doing this is to consider the task list and state that the task that appears to be the easiest to perform is valued as 2.  All other tasks are estimated relative to this task.  However it doesn’t have to be the smallest task, just a task the whole team can agree too.

So what do you use?  The Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, 34, etc.), t-shirt sizes (XS, S, M, L, XL, XXL, XXXL) or anything that starts small and ends up large.  The most important thing here is that the team understands and responds to the values that are being used.

Ok now onto Velocity.  What is it? Where does it come from?  Here is another answer that the powers that be won’t like…In the first sprint, we guess. It’s all about gut feeling, after a few sprints things will become clearer.

After each sprint the velocity is measured, after one or two sprints we have an average that we can use for predicting sprints in the future.  From this we can estimate the completion date.  With a little bit of thinking we can calculate values such as £/Story Points which can be used to estimate project costs.

The important word here is estimate!  It’s not definitive or fixed.

It is worth remembering that Story points can create a lot of vagueness within the agile process.  For every team, story size could mean different things depending on what baseline they chose, so you can’t cross estimate teams.  If two teams are given the same stories one team can say their velocity is 35 and the other 12 dependant on what numbers they choose.

If you use Story points in this way the Scrum Release Burn Down Chart can provide a fairly accurate picture of the progress of the project, and this will give the management a good overview of the projects progress, or lack of progress.

Demonstrating A Platform

Demonstrating a platform can be difficult.  When you reach the end of a sprint there is a great desire to show off what you have achieved over the period.  I have made the mistake in the past of rushing into an unstructured demonstration of the features and functionality.  This can lack direction and become confusing to the product owner/stakeholders.

Like so many things in life the sprint review is a sales excercise.  You are selling the base product and your scrum team’s achievements over the sprint to gain sign off so that you can move on to new user stories.

Plan the demo
Plan what you are going to show and in what order you will show it.  Think about the questions that you would ask if someone was demonstrating to you.  Prepare answers for those questions.

Think about your audience
Who are you running the domonstration for?  Can you see any obvious issues for those people that you can pre-propose a solution for?  What do your audience want to see, is it features, reliability, intutitiveness.  Sculpt your demonstration to cover these factors.

Pre-load content
No platform looks good without content.  The first bite is always with the eye.  No matter how good the functionality if the audience doesn’t like the way it looks they will not be able to see past the skin.

Pre loading test data is a great idea, but know your audience.  I loaded some copy for one client using Lorum Ipsom…their only comment…”Can we have our version in English?”

Most importantly pre-load enough usable data to effectively test the site.  Construct your data requirements around the demo plan and what you hope to achieve.  Make it look ‘full’.

Back up plan
Test your demo before you go ahead and show it so that you know it works.  Think about contigencies for if aspects of the demo are not successful, can you show something else to achieve the same result?

If technology fails on the day, which it often does, it is worth being able to speak about the platform with nothing infront of you to discribe the features and functionality whilst the team fix the error.