Skip to main content

Breaking the rule to reduce the waste

Last post 11:14 am September 10, 2015 by Ching-Pei Li
9 replies
12:17 pm August 26, 2015

If the PO planned to release the first version of the product at the end of fourth Sprint, is it possible to decrease the quality of Definition-of-Done during the earlier Sprint?

This is a realcase of customer.

For example, the DoD of every Sprint includes a piece of releasable software and help file.

To adhere the Scrum rules and the DoD of the Development organization, the DT must update the Help file and replace the Screen Shot of the software at the end of each Sprint.
The replacement of Screen Shot is a kind of waste.

Since the Increments of the earlier Sprint will not be release, the Scrum Team decide to break the rule to reduce the waste. The DT replaces the Screen Shot only at the Sprint which is planned to release a product.

I recommend moving the help file as a Product Backlog Item that can be select by the DT during the Sprint planning of the last Sprint of a Release Plan.

What do you think about it?
Any input will be welcome.


12:48 pm August 26, 2015

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.


08:57 pm August 26, 2015

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.


10:40 pm August 26, 2015

> 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.


01:10 am August 27, 2015

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.


06:34 am August 27, 2015

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.


04:36 am August 28, 2015


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!!


Anonymous
02:28 pm August 31, 2015


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?


08:58 pm September 9, 2015

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


11:14 am September 10, 2015


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.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.