Skip to main content

Due to the Russian invasion of Ukraine, we have paused all purchases and training in and from Russia.

[NewBie] Inherit and old project and trying to use Scrum

Last post 11:30 am September 29, 2014 by Ludwig Harsch
2 replies
05:20 pm September 25, 2014

I just attended an online course on scrum and agile. I am inheriting an old project and now trying to continue the development but with agile/scrum approach.

one of the things I notice is that the old code is of very poor quality and we need to make fixes to this code in order to improve its quality.

But my online course told me that items in the backlog are linked to user stories and something which end user could see and use.

So how do I fix the quality issues?

one approach I thought was that I should have a "cleanup sprint"... but then my team argues that this is waterfall in disguise.

your ideas?

[do not flame me. I have just attended a 3 hour course online on agile ... apart from that I know nothing other than coding and development]

01:52 pm September 28, 2014

Hi Abhishek,

Those "fixes to the code" should be integrated in the work done on a user story and you fix only the parts you're working on... don't touch anything in another part of the code base. Of course, before touching anything you should write tests. This is called "The Boy Scout Rule": "Always check a module in cleaner than when you checked it out.". This rule should be part of the Definition of Done. Also read about the "Broken Windows Theory".

Always try to improve things as you go, incrementally. This will slow you down a bit (at least initially), but at least it won't bring the project to a halt at some point. Explain this to your Product Owner so that he is aware of the situation (the "transparency" pillar of Scrum).

Here are some web resources:
1. Boy Scout Rule:
2. Boy Scout Rule:
3. Opportunistic Refactoring:
4. Broken Windows Theory:
5. Broken Windows Theory:
6. Refactor vs Rewrite:
7. Refactor vs Rewrite:…
8. The Tiger Team:
(search for "tiger" in the pdf and read that story)

And some books:
1. Clean Code (Robert C. Martin)
2. Working Effectively with Legacy Code (Michael Feathers)
3. Refactoring (Martin Fowler)
4. Pragmatic Programmers (Andrew Hunt)

Hopefully these links and books will give a starting point for your team.

11:30 am September 29, 2014

Hi Abhishek,
you can write Product Backlog Items (PBI) for the quality issues. There is no rule against this.
Every sprint has to deliver at least some functionality which the end user can use, but this does not apply to each PBI.
A cleanup sprint probably won't help you, because you would need plenty of them, and wouldn't deliver anything for end users. But what you can do is
1. stop creating more technical debt (quality issues). Start to write clean code and find ways to measure quality (static code analysis).
2. bring your Product Backlog in shape, including the quality issues, and plan some of them next sprint planning.
3. repeat from 2.
Yes there is no exit condition. Quality is not a state but a process.
Good luck!

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

Please note that the first and last name from your 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. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, 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 may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.