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.
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.
The term Task Board derives from Scrum.
Technical debt accrues when a design or construction approach is chosen that is expedient in the short term, 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
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.