Lean Agile Glossary
Conditions of Satisfaction
A statement authored by the Product Owner that tells an Agile team what test a Story must pass to be accepted as complete. A Story is not complete merely because the team say it is— the final say belongs to the Product Owner.
Iteration
Sometimes called a "sprint". It is a period of time where an agile team works to complete a set of Stories. This is typically from 1 to 4 weeks.
Product Owner
A new role in Agile that is closest to that of a Product Manager. An agile Product Owner is someone who thoroughly understands the reasons for the product or service being developed, who balances stakeholder needs, and sets the goals for the Agile team. The Product Owner does not direct the team— they are self-organising. Instead the Product Owner decides which work is highest priority, and so optimises the value produced by the Agile team for the business. This role can also be seen as being the Lean value stream manager.
Retrospective
A meeting that is held, usually at the end of each iteration, where an Agile team reflects on what worked well or poorly and comes to agreement on what things to do differently in the next iteration. "Inspect and Adapt" is a phrase used to describe the way Agile works— retrospectives are the point in the cycle where a team decides together how best to adapt so that they generate more value.
Story
A feature described in the language of the customer. An agile team will typically have about 8 to 16 stories that they complete in an iteration.
Story Points
A measure of value produced by an Agile team. Story points are a unitless number assigned to Stories to represent the inherent size of the software comprising the Story. If the work was not software but painting houses, then our unit of measure would be square feet, but not labour hours. A key problem in the software profession is the lack of a readily understood size metric, so people speak of size in terms of the hours it took to build a piece of software.
Story Points is a deliberate attempt to measure size of software independent of the labour hours needed to produce it. Agile teams use Story points because over time they can see their productivity change— if it used to take about 10 hours to produce 4 Story Points and now we can do it in 5 hours, then productivity has doubled.
TDD
Test-Driven Development. This refers to a method of writing software by first writing a small test, then just enough code to make that test pass. Every few minutes a new test is added, and then the code to make that test work is added. This is actually a technique for detailed design and coding, and is used by developers. The name often leads people to incorrectly assume TDD is done by Testers.
A statement authored by the Product Owner that tells an Agile team what test a Story must pass to be accepted as complete. A Story is not complete merely because the team say it is— the final say belongs to the Product Owner.
Iteration
Sometimes called a "sprint". It is a period of time where an agile team works to complete a set of Stories. This is typically from 1 to 4 weeks.
Product Owner
A new role in Agile that is closest to that of a Product Manager. An agile Product Owner is someone who thoroughly understands the reasons for the product or service being developed, who balances stakeholder needs, and sets the goals for the Agile team. The Product Owner does not direct the team— they are self-organising. Instead the Product Owner decides which work is highest priority, and so optimises the value produced by the Agile team for the business. This role can also be seen as being the Lean value stream manager.
Retrospective
A meeting that is held, usually at the end of each iteration, where an Agile team reflects on what worked well or poorly and comes to agreement on what things to do differently in the next iteration. "Inspect and Adapt" is a phrase used to describe the way Agile works— retrospectives are the point in the cycle where a team decides together how best to adapt so that they generate more value.
Story
A feature described in the language of the customer. An agile team will typically have about 8 to 16 stories that they complete in an iteration.
Story Points
A measure of value produced by an Agile team. Story points are a unitless number assigned to Stories to represent the inherent size of the software comprising the Story. If the work was not software but painting houses, then our unit of measure would be square feet, but not labour hours. A key problem in the software profession is the lack of a readily understood size metric, so people speak of size in terms of the hours it took to build a piece of software.
Story Points is a deliberate attempt to measure size of software independent of the labour hours needed to produce it. Agile teams use Story points because over time they can see their productivity change— if it used to take about 10 hours to produce 4 Story Points and now we can do it in 5 hours, then productivity has doubled.
TDD
Test-Driven Development. This refers to a method of writing software by first writing a small test, then just enough code to make that test pass. Every few minutes a new test is added, and then the code to make that test work is added. This is actually a technique for detailed design and coding, and is used by developers. The name often leads people to incorrectly assume TDD is done by Testers.