A short, daily all-hands meeting in which members of an Agile team address three key questions:
What did you get done since the last stand-up?
What will you do before the next stand-up?
What impediments stand in your way?
The meeting is held at the same time and in the same place every day, with team members standing in a small circle. The point of standing up is to discourage the kinds of tangents and discursions that make for meeting hell, and the meeting is usually time boxed to no more than 15 minutes. The stand-up focuses on peer-to peer coordination through information exchange, and the meeting serves to raise the visibility of each person’s work and to ensure work integration. Only members of the development team participate, as many people as can comfortably stand in a small circle.
Etymology
The concept of the Daily Stand Up meeting originated with Extreme Programming. It was adapted to Scrum, where it is known as the Daily Scrum or Scrum.
The process of breaking user stories down into (a) smaller, more easily implemented user stories or (b) tasks. Likewise, epics may be decomposed into user stories, and tasks may be decomposed into more fine-grained tasks.
Story splitting is usually performed during backlog refinement and sprint planning. It is an important precursor to story sizing (estimation). Story splitting may also occur throughout the development process.
In the typical product backlog, user stories grow more fine grained as they near implementation and are larger and less detailed the further down the queue they reside.
A system is a group of interacting or interrelated elements that act according to a set of rules to form a unified whole. A system, surrounded and influenced by its environment, is described by its boundaries, structure, and purpose and expressed in its functioning.
Your digestive tract is a system. The components include: mouth, stomach, and intestines. The components work together as a system to digest food and drink. The travel industry with buses, trains, planes, UBERs, Taxis, and hotels works together as a system to allow us to travel for business or pleasure. These systems rely on a group of interacting elements that act according to a set of rules to create a unified whole.
Understanding system thinking is understanding a system, everyone, and everything that helps create, grow, and maintain that system. The system can include people, organizational design, physical and technical environments, other parts of the whole system.
Craig Larman and Bas Vodde begin to describe systems thinking in their book “Large-Scale Scrum: More with LeSS”:
“The first step of systems thinking is simply recognizing that there is a whole system, with elements that influence one another within a whole. These influences can have delays, create reinforcing cycles, and have unintended or hidden consequences, with a cascade of new influences.”
Suppose we are not looking at the whole system. Instead, we focus only on local optimation, which would be considered only part of the entire system (e.g., solving a business need/problem on the product interface (UI), regarded as local optimization). Local optimization might help us understand a business need from a UI customer interaction; however, it fails to understand how the UI will interact with the middleware, application layer, database layer, etc. This, to build products and services from a customer’s need, we need to know the entire system.
In August Bradley’s YouTube video under “Further Learning” section below, he discusses 6 steps to systems thinking:
Identify and define the inputs, outputs, and movements of the system, setup
Distinguish linear from circular, what functions in the system are linear, and what processes are circular
Look for patterns
Find the feedback loops, self-magnifying or self-diminishing patterns over time, step
Understand the balancing processes that will help to maintain equilibrium within the system, step
Study your system’s interaction with other systems.
These steps above will help you better understand how to identify, define, and maintain complex systems and how your system may exist within a much larger global system.
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.
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.
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.
