t is for...

In Scrum and Extreme Programming, a unit of work, estimated in hours. During the iteration planning meeting, user stories are decomposed into tasks. In his book, Agile Software Development with Scrum, Ken Schwaber writes, “Tasks should have enough detail so that each task takes roughly four to sixteen hours to finish.”

In practice, many Agile practitioners vary from this formula, by preferring more granular tasks, or more abstract sizing units than hours(e.g., story points). Some do not decompose stories into tasks at all, preferring to add user stories directly to their task board.

Etymology

Unknown.

Resources

Agile Software Development with Scrum by Ken Schwaber and Mike Beedle

Iteration Planning on www.extremeprogramming.org.

Also Scrum Board

A type of information radiator that presents, at minimum, “to do” “doing” and “done” columns for organizing a team’s work . Some teams include their backlog as a column on the task board, while others limit it to work to be performed during the current iteration. Ideally, the task board is a physical thing, consisting of notecards or sticky notes affixed to a wall, although distributed teams may use an online task board application.

In Scrum, the Scrum Board is populated with tasks for the current sprint, while other Agile teams may populate it with User Stories.

Etymology

The term Task Board derives from Scrum.

See Definition of Done.

Technical debt is an obligation that an organization incurs when it chooses a design or construction approach which is expedient, but increases complexity and is more costly in the long term. That is, some aspects of quality are deferred for the sake of faster delivery.

The metaphor of technical debt is compared to monetary debt. If it is not repaid, it accumulates ‘interest’, making it harder to implement changes later on. Another way to view it is that when technical debt is not addressed it results in increased software rot in the case of software.

The term originated in software development, but may be applied to other fields. This entry describes the term as applied to software.

Technical debt includes, for example, postponement of:

• Refactoring code to reflect improved understanding of the software design and architecture
• Refactoring code that is confusing and difficult to modify
• Writing automated tests
• Fixing bugs

When technical debt accumulates there are various harmful effects to the business, such as:

• It becomes increasingly difficult to implement new functionality
• Stakeholders are upset when new features take longer and longer to deliver
• Developer morale decreases
• Delivery timelines become less predictable

Note that technical debt is not inherently good or bad. It depends on how it is used, what the tradeoffs are, and what the intent is. The following five-minute video with Ward Cunningham who originated the term is clarifying.

Background of the Term

The metaphor was described by Ward Cunningham in the article The WyCash Portfolio Management System

Further Learning

Technical Debt – ProductPlan – blog post
Technical debt – Wikipedia – wiki post

See Iteration and Iterative Development.