Scrum and The Software Poverty Trap

Scrum is an iterative software development methodology delivering increments of work in sprints. Each sprint is a time-boxed period where the development team works on a backlog of items prioritised by the product owner.

This time-boxing is similar to the pay-check budgeting often evidenced in personal poverty traps. If not managed the budget is used up implementing any new work at the expense of debt incurred in the previous periods.

Projects that use Scrum while only monitoring velocity and amount of work delivered could be in a poverty trap without realising it, and risk falling further into a debt spiral.

To prevent this happening a balance sheet of value against technical debt must be used to assess the liquidity of the project and restructure or refinance its technical debt when required.


This paper examines the author's experience of Scrum and its effect on Technical Debt at the internal software engineering department in a Fortune 500 company, referred to herein as “the company”.

Technical Debt

The idea of technical debt was first coined by Cunningham in 1992 [1]. Technical debt just as financial debt varies in its form and cost, consisting of principal debt and interest [2].


Scrum is a  popular choice of agile software development methodology, VersionOne Inc [3] reported 56% of those using agile methodologies are using Scrum and a further 28% using a Scrum hybrid methodology e.g. ScrumBan.

The Scrum Guide [4] describes the methodology framework as "lightweight" and simple to understand, but challenging to master; it defines roles, events and artefacts and the rules used to operate the framework for a project.

The Scrum roles are; Product Owner (PO), Scrum Master (SM) and Development Team. The Development Team encompasses anyone who does work to deliver a potentially releasable increment of the software. The events are; The Sprint, Sprint Planning, Daily Scrum, Sprint Review & Sprint Retrospective. The artefacts are; Product Backlog, Sprint Backlog and Increment.

Story Points & Velocity

User Stories (stories) originated in Extreme Programming (XP) [5] and are usually used to describe the items of work in the product backlog. The Development Team estimate a value of story points for each story; this unit of measure estimates the work and combines the amount of work, the complexity of the work, and any risk or uncertainty of the work.

The Development team commits to deliver a number of story points in a sprint, and after some iterations, a running average calculated; this is the velocity. The team, using the velocity, can compute (or revise) an estimate of how long the project will take to complete, based on the estimates associated with remaining user stories and assuming that velocity over the remaining iterations will remain approximately the same.

Software Poverty Trap

A poverty trap is a self-reinforcing mechanism which causes poverty to persist [6]. A typical example of this is living paycheck-to-paycheck where an individual’s entire earnings for a period are expended on all living costs and not having anything left before receiving their next paycheck.

In the comparison between the paycheck-to-paycheck and the sprint; both have a set period and start with an allowance to be spent in that period. In the Sprint a Development Team uses the allowance to build the stories in the sprint backlog as decided by the PO. The PO will be making those decisions on what will please the stakeholders most.

Technical Debt Spiral

In the worst cases of software development, the cost of financing the technical debt, either by reducing the principal or lower interest rates, out ways the business value of the software.  A clear example of this would be an eCommerce website, where the cost of implementation and maintenance is greater than the income it generates. The project will need to restructure or refinance its debt [2], or written off.


The senior management of the company, like many others, wanted to move software projects from traditional waterfall software delivery lifecycles to modern agile methodologies. This new direction coincided with the decision to move software development to in-house teams rather than using external vendors.

New software development centres were set up around the world, and new teams recruited. These new teams would only use agile methodologies, specifically Scrum for projects. 

The company saw many of the anticipated benefits of agile with increments being delivered quicker and aligning closer to the user’s requirement. To further the use of agile methodologies goals were set (affecting performance related pay) to increase adoption.

The stakeholders and decision makers for projects regularly used velocity as a measure of success and progress of projects, this in part was because the velocity was the reporting mechanism the Scrum team used to demonstrate progress. Scrum teams were encouraged to increase or at least hold velocity steady, any reduction in velocity would have to be explained in project management meetings.

The company’s software quality assurance team required that all user stories conform to the Connextra template [7]:

As a <role> I can/want <capability>, so that <receive benefit>.

This led to ‘fake’ stories [8] where the user is a system, or the user does not directly receive the benefit or have an intangible benefit. It was difficult to estimate the story points for these fake stories and identify the actual business benefit from doing the work. E.g.

As a product owner, I want to release version 11 deployed to production so that customers can use it.

Bugs and re-work were not story pointed; this is as standard and reduces the Development Teams velocity as the re-work is not counted towards work delivered. In one project with multiple Scrum team, it was agreed to start story pointing tasks, this gave value to the work done outside of stories, e.g. “Deploy release 11 to production” and avoided creating fake stories.  

These constraints and limited methods of reporting made it difficult for the Development Team to place value and benefit on technical debt re-work or future invest and explain to the PO why they should be prioritised. The PO was also incentivised to prioritise new features the demonstrate to the stake holders that work was being delivered each sprint.

This experience mirrors that reported by Santos et al. [9] that “After Scrum adoption, the most visible symptoms of dysfunction in our software development department were related to agile engineering practices, where teams were accumulating a huge amount of technical debt.”


Scrum teams must stop reporting velocity to stakeholders and decision makers, and those decision makers must also accept that it is not a useful measurement for management of projects.

Stakeholders need to be concerned with the value delivered, not the amount of work done.

Business Value

Impact Mapping [10] is a simple method for assigning a business result value to every story by relating it to the core project goal. This method is used to help in the prioritisation stage, but it is also an indicator of the value of the work done, unlike story points and velocity which only show the amount of work done. Gilb [11] and others [12] have proposed more detailed ways of assigning business value or benefits to each piece of work in a project. One of these methods should be used to assign a value to all stories in a project.

Story points will still need to estimated, with this information a cost-benefit analysis can be done against each story. The benefit and cost of debt repayment stories should also be calculated using a similar methodology.

Prioritisation can be done on the stories that will bring the most benefit at the lowest cost, and the value delivered by the team can be reported to stakeholders.


Scrum teams should use alternative story format as required and drop the “user” from the name [8]. In this example, there is no user, and it does not follow the Connextra template, but its intent and the business benefit is clear.

Improve performance of system Y by X%, so that the server cost is reduced.

Stories for investment can also be written, this might include training for developers, which can be compared to a savings account and will have a value to the business.

Development team to attend training on external system A so that they can implement an integration.

The above is an example of a story that could prevent future technical debt, the development team could build the integration without the training, but it would be more likely to need re-work in the future.

Future Directions

At Commerce Labs, we will be working to test the proposition in this paper with multiple companies using Scrum for new projects.

Following Akbarinasaji & Bener [13] we will be devising a reporting mechanism that technically minded Scrum teams can use to report the equity of a project to financially minded project sponsors and stakeholder.

We will also create a Software Poverty Trap assessment toolkit for existing projects to assess their liquidity.


It is not the Scrum methodology itself that causes software poverty traps. In a corporate environment where performance related pay needs something to measure, the velocity is an easy option, but this influences a Scrum team’s decisions; their goal may not be in the best interests of the software project.

Users of Scrum must consider the best measures for the success of the project, the true equity of a project is the value the software has, less any technical debt it holds.


  • [1] Ward Cunningham, "The WyCash portfolio management system," OOPS Messenger 4, vol. 2 (1993), pp. 29-30, 1993.

  • [2] R. Zablah and C. Murphy, "Restructuring and refinancing technical debt," in 2015 IEEE 7th International Workshop on Managing Technical Debt (MTD), Bremen, 2015, pp. 77-80.

  • [3] VersionOne Inc. (2018) 12th Annual State of Agile™️ Report.

  • [4] K. Schwaber and J. Sutherland, "The Scrum Guide™️," 2017.

  • [5] K Beck, "Embracing change with extreme programming," IEEE Computer, vol. 32, no. 10, pp. 70–77, 1999.

  • [6] C. Azariadis and J. Stachurski, "Poverty Traps," in Handbook of Economic Growth.: Elsevier, 2005, vol. 1.

  • [7] P. Szabo, User Experience Mapping.: Packt Publishing, 2017.

  • [8] G. Adzic and D. Evans, Fifty Quick Ideas to Improve Your User Stories. London: Neuri Consulting LLP, 2014.

  • [9] P. S. M. Santos, A. Varella, C. R. Dantas, and D. B. Borges, "Visualizing and Managing Technical Debt in Agile Development: An Experience Report," in Software Engineering and Extreme Programming Lecture Notes in Business Information Processing, vol. 149, 2013, pp. 121-134.

  • [10] G Adzic, Impact Mapping: Making a Big Impact with Software Products and Projects.: Provoking Thoughts, 2012.

  • [11] T. Gilb, Competitive Engineering: A Handbook For Systems Engineering, Requirements Engineering, and Software Engineering Using Planguage.: Butterworth-Heinemann, 2005.

  • [12] J. Hannay, H. Benestad, and K. Strand, "Agile Uncertainty Assessment for Benefit Points and Story Points," IEEE Software, October 2018.

  • [13] S. Akbarinasaji and A. Bener, "Adjusting the Balance Sheet by Appending Technical Debt," in IEEE 8th International Workshop on Managing Technical Debt, 2016, pp. 36-39.