Often I get to hear “how much documentation should I do”? How long should be my Sprint Planning or Sprint Retro?
I say Just Barely Good Enough(JBGE). Check out below picture by Scott Ambler.
This graph summarizes above questions using law of dimishing returns which shows value curve for an artifact being just barely good enough. You invest effort till you achieve effective point the dashed line in the graph.
Value refers to the net benefit of the artifact, which would be calculated as benefit – cost. Anything on the right implies your incremental efforts are not returning equivalent or higher value back. Anything on the left of dashed line indictates you have some more work to do to achieve JBGE.
If an artifact or any Scrum Ceremony is already JBGE(or better)then doing more work on it is clearly a waste.
Let’s take an example of documentation here:
Team spends too much time many times without knowing to whom we are building this or for what purpose. Everytime you don’t need a very detailed documentation. How many times you as a developer have read 100-200 pages technical design document? I must confess that I have not anytime in my career. They become stale very soon and cost of keeping them updated is very high. Apply JBGE value curve here.
This does not imply that you are creating low quality. Quality of the artifact is in the eyes of the beholder, not the creator of it. If your stakeholder requires very detailed document, then JBGE for that artifact is when it reaches that level of excellence and detail.
I ask my teams to have documentation like code commenting, interface specs documentation etc to be part of done criteria for a story. If your stakeholder requires detailed documents like User Manual for end user, or System documentation for maintenance, then add it as part of your product backlog. Let team take advantage of this effort by adding it into final velocity figures of the sprint.
Have you run into similar situations on your projects or in your life? Please share your experiences…
Mansur says
Not agree that everything is so “black and white”. More effort may bring much better value is the final product is really perfect! So it depends from which side you are looking at the situations – product owner or the team.
Avienaash says
Yeah you are right, nothing will be so black and white. You will come to a effective point as shown in graph by practicing. If you see there is a difference in perspectives between PO and team, then we have to bridge this. These differences should come up and should be discussed. You can apply JBGE concept almost anywhere in project or in real life.
Malcolm Lisle says
I agree with the principle you are putting forward in that in Agile and Scrum in particular you do not want to waste effort on things that will not give value, but I feel the way you are betraying it gives it a negative flavour.
I would flip this over and instead of saying Just Barely Good Enough (JBGE) say something along the lines of Good Enough To Save Waste (GETSW).
It’s the same thing but highlighting the benefit of saving wasted effort rather than giving an impression of being slap dash.
Avienaash says
I agree, removing or reducing waste is what team should focus on.
Rahul Agrawal says
Identification of Good Enough. Yes that’s the biggest challenge. The other thing is drawing the line where to stop. Often the life of such line is short lived. One needs to also be aware to identify when the line needs to be redrawn.