Breaking the rule to reduce the waste

The replacement of the screen shot isn't waste, because an updated help file would genuinely be needed if an increment was to be released.

The waste being incurred is product depreciation. Since no release occurs until Sprint 4, the value being accumulated cannot be harvested until that point. There will be no return on investment. The completed work will become gradually less relevant to continually changing business needs, and there will be missed opportunities to elicit feedback from the market. That's the waste you should try to eliminate.

Hi Ian,

Thanks for your reply.

This is a real case of my customer.

In the early stages of a new products, it does not make sense to release the product to market at each Sprint. Of course, the Scrum Team has Sprint review event. During the Sprint review, the Team demo the features to stakeholders.

Due to the maintenance of the draft help file has occupied a lot of resources of the Team, especially the work to replace the screen shot, and the knowledge acquiring cost in the early stages, there are few “Done” features to demo at Sprint review. The results decrease the interesting of the Demo for stakeholders.

There should be a tradeoff ...

Any input will be appreciated.

> In the early stages of a new products, it does
> not make sense to release the product to
> market at each Sprint. 

Why not flex the scope so something *can* be released each and every Sprint?

Remember that a useful MVP does not have to be marketable in itself. It just needs to elicit useful information from the market, so the feedback loop can be closed.

To add to Ian, Sprint goals also play an important role in coming up with a releasable MVP. Craft Sprint goals in such a way that you come up with short expression of the purpose of Sprint. This goal would focus towards providing solution to a business concern.

Can the product be released without the help file? Would it be usable by customers?
If so, stop reading and move that help file from the definition of done to the Product Backlog.
If not, read the following.
Scrum is a tool to achieve business agility, and every Scrum rule serves a specific purpose to this goal.
If you break the rule (before having reached "Ha" level), you might win some time in the short term. However it will not make you more agile, because something is missing that forces you to improve.
If you stick to the rule, your team might get so annoyed by creating the same screenshot over and over again that they will find a way to automate that (good developers are usually lazy developers, and good documentation is usually generated documentation). So you win time in the long term and become more agile.
Plus, you have a potentially releasable increment each sprint.

Posted By Ludwig Harsch on 27 Aug 2015 06:34 AM
Can the product be released without the help file? Would it be usable by customers?
If so, stop reading and move that help file from the definition of done to the Product Backlog.
If not, read the following. .

Thanks for your valuable input.

I should also mention, just in case it's not obvious.
1. This is a "NEW" product development.
2. The product do not be release to real customers at early stages. This is a business strategy.
3. When the Team demo the product to stakeholders at Sprint review, no body need the help file.
4. An Up-To-Date help file is defined in DoD.
5. The DT spent much time to edit and to replace screenshot due to the UI changed every Sprints.

This is my new customer.
Before the beta test for selected customers and support teams, the help file is low valuable.
It real odd for me when I found the problem.

My opinion is:
If an up-to date help file is needed for DoD, the DT must finish it at the end of each Sprint.
If an up-to date help file is really a waste for early stages, move it to Product Backlog from the DoD.
Do not break the rule.

Any more input will be appreciated!!

Posted By Ching-Pei Li on 28 Aug 2015 04:36 AM
... 3. When the Team demo the product to stakeholders at Sprint review, no body need the help file. ...
5. The DT spent much time to edit and to replace screenshot due to the UI changed every Sprints. ...
Before the beta test for selected customers and support teams, the help file is low valuable. ...

Ignoring the definition of done, are the screenshots in the help file necessary in the first place? Is the help file itself necessary? If the answers are yes, then is there a method of storing/hosting the screenshots/help file that will reduce the overhead of having to update?

I would ask some key questions.
Why does the DoD include work that is potentially of no value?
Why does the PO insist on work that is of potentially no value?
Why does the Product Backlog include work that is repetitive and potentially redundant?

From a Six Sigma perspective, avoiding re-doing work is one of the key improvement strategies.
I would suggest the DT re-negotiate with the PO what the DoD includes, and alter the Product Backlog priority so that the required documentation for release is only included to be completed in Sprints where it can potentially be released.

P

Posted By Peter Green on 09 Sep 2015 08:58 PM
From a Six Sigma perspective, avoiding re-doing work is one of the key improvement strategies.
I would suggest the DT re-negotiate with the PO what the DoD includes, and alter the Product Backlog priority so that the required documentation for release is only included to be completed in Sprints where it can potentially be released.

Thanks for your input.

Your suggestion is actionable.