I like getting paid.
I am not saying that I go to work for a paycheck - I love what I do - but a person has to eat and to eat they need to get paid.
For this reason I suspect you like getting paid too.
This is not a bad thing. It simply creates the reality that someone is going to have to pay for all the work that you do in a day. We call that person the customer. Whether the customer is a larger company or 100,000 teenagers they are going to have to pay for each line of code that you develop.
The truth is that this actually creates a simple answer to a complex problem. Often when developing software it is hard to know where to draw the line when it comes to features, documentation, etc. People often debate this for hours. It is actually pretty simple:
Make sure the customer is willing to pay for everything that you do.
It turns out that this actually can be broken down into two categories of user stories:
- Stories that have value so the customer is will to pay for them. (this might be that new feature you are working on.)
- Stories that have no value but are required to get paid. (this might be the documentation needed to use the new feature.)
Think of this as working and filling out a time sheet: you need to work to get paid and you need to fill out your time sheet to get paid. Valuable stories and required stories. Pretty simple.
In Scrum this simple concept forms the basis for a product backlog. The Product Owner (a representative of the customer) and the ScrumMaster make a list of stories and then assign a value to them. The team then estimates how hard a task will be to complete - lets call this the effort. Sort the list by dividing the value by the effort. Again, simple.
Priority = Value / Effort
Things only get a little tricky when we talk about required stories (the ones without value that are still needed to get paid). These should be kept up to date with the progress of the project. For example, a required manual should be updated once a feature is demo’d. This way the product can be released as needed with little notice.
As you work through the list you will eventually realize that at some point the value returned by a stories does not pay for your development costs to produce it. This is when you wrap the project up and deliver it. Again, simple.
So to recap here is the way to prioritize your work:
- Only work on stories that get you paid:
- this can mean stories with value or
- this can mean stories that have no value but are required.
- Don’t work on anything that is not required to get paid.
- Priority = Value / Effort
- Sort your list by priority.
- Even thought the priority of a required story is essentially zero, keep required stories up to date with your current progress so that you can deliver the product as requested by the customer.
- The project is done when the customer is happy with the current features or when it will cost more to develop a story than it is worth to the customer.
Follow these rules and you will get paid.
And you will be happy.
And your customer will be too.
Start small. Think BIG.
