Teams working under a scrum model very often talk about the relentless pace of scrum. There seems to be a constant pressure on getting new work done. So much so, that a lot of teams feel that there is no time allowed for personal development/technology investigations or even refactoring of the systems the team is responsible for.

Typically, teams in scrum, get a group of stories from the customer. The team is then expected to execute on these stories, getting them completely developed and tested prior to the end of the iteration.

What gets lost, often times, is the realization that the teams are not responsible for delivering stories. The teams are responsible for delivering a system. The outcome of a particular sprint/iteration is not a group of completed stories, but rather a high-quality system. Once that paradigm shift happens, then it makes it very easy for teams to find time to accomplish some of the things that they previously thought they were unable to do because of scrum.

Teams have a fair understanding of the amount of technical debt that they are accruing interest on. It is perfectly within that team’s right to take on fewer stories so that they can address the technical debt.

It is important that teams realize that they control their own velocity. The teams dictate the amount of work that they will take on for a given iteration. Teams should certainly be allowed to take on a little less new work to address some technical debt.

We, as agile development managers, need to encourage teams to deliver effective systems. It is not conducive to measure teams on velocity alone.