Tip 1: Work smart, play smart
The first step to avoid over-engineering in agile scrum is to – you guessed it – have a dialogue. Come to a mutual understanding with your team about the ways in which you can work smarter, not harder. It won’t be hard to persuade them.
One suggestion is to introduce the Pareto Principle or 80/20 rule. The 80/20 rule dictates that 80% of the value can be realised with just 20% effort when invested the right way. Therefore, teasing out the remaining 80% of the effort will only unlock around 20% of the remaining value–time and effort that could’ve been spent elsewhere.
Have an upfront conversation on this with the whole team and discuss how you can apply this rule to the level of fidelity in the work.
“Combatting gold plating is an important tool to help you improve your pace and solve for the user’s needs”
Tip 2: Define your done already!
By the time you’re planning and refining work items with your scrum team, you should have active and agreed definitions of a ‘ready’ work item. Remind your team of this agreed definition so that they can hold each other accountable if they start over-preparing items before they are pulled into a sprint.
The same goes for your agreed definition of ‘done’, and the level of quality you’re happy with before the item can be classified as done. The definition of done describes, not the minimum, but THE level of quality and fidelity that the item must meet.
Active use of ready and done is another key tool to ensure you’re only polishing work to the agreed level, and not beyond. Please see my previous posts on the best ways to come to an agreed definition of ready and a definition of done.
Tip 3: It’s OK that it’s OK
As a team you’ll also need to accept that the fidelity of the work will change throughout the lifecycle of the product. That is to say, as the product develops, the level of fidelity should go from low to higher along with the overall quality.
At the beginning of the product’s life, you should be looking to establish product market fit. The team will produce low fidelity pieces of work to test assumptions and get feedback on the value proposition. Once the product becomes more established, they will produce higher fidelity work to meet the high expectations of users–however be mindful not to aim too high, particularly with new features.
If you find it difficult to determine the right level of fidelity for your position in the product life-cycle, the safest bet is to treat everything as a minimum viable product (MVP). That means no matter which stage of the product’s development your team are working on, they execute the work at the lowest fidelity level necessary to achieve the desired outcome.
I hope the video and tips above help you to combat the all-too-familiar desire to gold-plate, both in refinement and during the sprint iteration. From here, I’d advise you to watch part two of my tips for avoiding gold-plating and how to stop over-engineering in agile scrum.
If you have any questions or topics you’d like me to cover, leave a comment below or send me a message through my website. Thanks for reading. See you next time!
Here’s the full transcript:
-Hi Georg Fasching here helping you unlock your team’s genius.
In this video, I’m focusing on gold plating or over engineering of product backlog items that a team is working on delivering together in their planning iteration.
A very important subject helping you to improve the pace overall at which you are able to solve for customers and user needs.
And with it being so important, I’m doing a double whammy on this one.
So normally Power free Series is three tips in three minutes and we’re starting with the first one now.
So the first step to help you combat gold plating is to have an open conversation in your team on the topic of the 80:20 Rule or Pareto’s principle.
Pareto’s principle suggests that we actually only need to invest about 20% of the effort in order to return 80% of the value.
Suggesting that on the inverse, if we delved into the
remaining 80% of effort we would actually only then
add an extra 20% of value if we pursued that completely.
So I think this is a good thinking tool to explore together with the team and see how that resonates with them as it comes to the level of fidelity and quality that you are delivering your product features in.
And with that being a team conversation that you have upfront it’s also done a good reminder point that it can go back to with the team.
The next suggestion and tip that I have for you in order to refrain from gold plating and over-engineering as a team is to make active use of our definition of ready as well as your definition of done.
For the definition of ready, you want to have backlog items ready, but that also has a level of fidelity in there that needs to be deduced very carefully and there’s a video available on that as well.
When it comes to then the actual delivery of items through the planning iteration you need to refer to
the definition of done.
There’s also video available in the series.
So by active use of the definition of ready throughout the spring where you are very clear on the level of fidelity and the level of polish that you have agreed on together amongst team and product owner, that is another key tool to ensure that you’re only developing things across the entire team to the agreed level and not any further.
And last but not least, there is the consideration around making the level of fidelity and quality that you’re developing to congruent with the position of the product in your product life cycle.
And that then also would be reflected in a definition of ready and your definition of done.
So there is this way of looking at it that for products very early on in the life cycle when you’re perhaps even still addressing product market fit, the level of fidelity can be really, really low, because all you need to do is testing assumptions, whereas when you have a
more established product, it needs to be somewhat higher but not too high.
So having the level of fidelity understood over the course of the life cycle and having that on active conversation with the team is a key point in that.
The extreme way of looking at this is actually to say everything is an MVP.
Everything that you touch regardless of where it is on the product life cycle just to at least have as a thinking tool is you always develop to the lowest level necessary in order to achieve the outcome that you wanted to achieve.
Everything is an MVP so to speak, and with that we have reached the end of our time box for this video.
As I said this is going to be a double whammy.
There will be a second one.
I’m sharing three more things on gold-plating.
So you can choose whichever works best for your context or all of them if you like and coming again in the Power free Series.
Thank you very much for your time.
If you have any thoughts or comments on this video or questions, please share them down below.
If you’ve found something useful in this, please like, share, and subscribe and until the next video all the best for the practice with your team.
Thank you very much.