Scrum Software

How does agile development handle change?

Agile seeks to leverage change through inspection, adaptation, and transparency.

How much time should be allocated to grooming?

As a general rule, 10% of sprint time should be dedicated to grooming.

How fast is development?

Fast, but not rushed.

What is preference for people over work waste?

Focus on idle work, not idle workers.

When is quality built into the product?

From the beginning as opposed to mostly at the end.

How are WIP (work-in-process) handled?

Inventory is recongized throughout sprints and it is managed to achieve good flow.

How is the cost of delay handled?

It is always considered in making decisions about development.

What kind of characteristics need a product owner have?

She needs domain skills (being a visionary for the product, knows not everything can be anticipated up-front, and has business and domain expertise). She needs people skills (good relationship & comm. with stakeholders, good at gathering consensus, powerful motivator). She needs decision making ability (is empowered to make decisions, willing to make hard decisions, decisivie, and balances economic and technical needs). She needs accountability (accepts responsiblity for the product, committed and available, and acts like a scrum team member).

How much work is completed withing a sprint?

Smaller, economically sensible batch sizes are used throughout sprints.

What is the product owner responsible for?

The finished product of the scrum team; thus, he collaborates with scrum master and dev. team often. This person is a main interface between the client and the rest of the scrum team.

How can we manage the accrual of tech debt?

The first step is to use strong technical feedback, such as test-driven development, continuous integration, simple design, etc. Next, we can use a strong definition of done to help ensure that we are very confident that the software we develop works well and is bug-free and well-formatted, styled, etc. Finally, we can truly understand the economics of technical debt in order to truly weight the decision to rush development for a release. Releasing a product early will likely present an immediate economic win over taking the time to stop technical debt; however, if the team is not diligent about paying back its debt, the short-term win may not stay for the long-term.

What are the principal activities involved in "grooming"?

The principal activities of grooming are adding/refining (breaking into smaller) PBIs, estimating PBIs, and re-prioritizing PBIs.

What is the scrum master responsible for?

The scrum master helps the scrum team build its own scrum approach and ensures that the scrum process continues to be efficient. The scrum master is between a very experienced developer and an experienced scrum member.

What kind of PBIs exist in the product backlog?

The variant forms of PBIs include features (new functionality), improvements (to existing functionality), technical improvements, bug-fixes, and knowledge-acquisition work.

Why timebox a sprint?

Timeboxing, establishing a start and end date to a sprint during which work according to "done" will be delivered, is beneficial.

What is centric?

Value-centric: valuable product output is king.

What are the scrum roles and how are they defined?

(1) Product owner - Person who has the "big picture" goal for the end product (what will be developed) and in what order it will be developed. (2) ScrumMaster - A person who's responsible for helping the scrum team continue to improve its scrum process of development based on scrum framework. (3) Development Team - A team of 5-9 people who determine how to complete for what the product owner has asked.

Describe the steps of a scrum sprint

1 Product Backlog is groomed throughout 2 Sprint is planned by the scrum team 3 Sprint backlog is created by the dev. team 4 The sprint is executed, and a daily scrum is performed 5 "Done"...a potentially shippable product increment 6 Sprint review is performed (product feedback) 7 Sprint retrospective is performed (scrum process feedback)

What is a sprint goal?

A goal that describes the business purpose and value of the sprint, typically focused to a single end, but may at times be multifaceted.

What are knowledge acquisition stories and when are they useful?

A knowledge acquisition story is a story created to buy some type of information through exploration. They are useful when the team is halted from making progress on a feature, because of a lack of knowledge AND the cost of undoing the work by making a guess and redoing the work elsewhere (feedback/adapt) is more costly than buying the information which would enable the work to be done.

Who should be a sm?

A scrummaster is someone who comes from usually a somewhat technical (e.g. development, testing, etc.) background and has the time to perform scrum-master roles (as opposed to those who should be leveraging tech expertise most of the time). A SM is usually not a full time role, and it can usually be performed with other roles (e.g. scrum master of multiple teams, scrum master and tester, etc.)

What's a sprint?

A sprint is a timeboxed (fixed start and end date) cycle during which a potentially shippable product is produced as a result.

What defines a sprint?

A sprint is the heart of the scrum framework, in which planning, execution, retrospective, and review take place. It is a timeboxed period during which a potentially shippable product is delivered according to a definition of done.

what's a story point?

A story point is an agreed-upon relative unit of how long something will take. Usually story points are assigned to a task for a PBI and averaged across the team.

How and why should we calculate a velocity range?

A velocity range can be easily calculated by taking 90% confidence intervals of the teams velocity low and velocity high, and using this range for calculations. Using a range as opposed to an average is superior, because it favors accuracy and reduces precision (which is artificial because more precise is more prone to error).

List and explain a few consequences of technical debt.

An unpredictable tipping point for the product, product atrophy, increased development costs, and universal frustruation. Unpredictable tipping point: Essentially, the tipping point of a product is the point in time when any change to the product causes chaos; with increasing technical debt, the chances of reaching this point increase, and it's hard to revert back once this point is reached. Product atrophy - Because tech debt is high, it's hard for the development to fix bugs and implement new features. This causes the product to atrophy and become known as "old" in the market. Increased development costs - When technical debt is high, even seemingly simple changes become hard to implement and take a lot more time (therefore cost a lot more). Universal frustruation - The customer becomes frustruated with the product (therefore the business team), the business team becomes frustruated with the dev team, the dev team becomes frustruated trying to work out of debt.

Which and how many product backlogs should we have?

As a general rule, one product to one proudct backlog tends to work pretty well. However, this has its limitations. For example, if the application is a suite of apps (like MS office), do we create PB per app, or for the whole app? Generally, where possible, sticking with one PB for one product, even big ones, is good where possible. However, for huge projects it's just impossible and inefficient in certain scenarios.

Explain the three different levels of estimation, when these are estimated, and the metric used.

At the highest level, estimation occurs in the portfolio backlog. A company typically maintains one of these in an ongoing process to keep a handle on every product it's building; the company may choose to estimate these projects in terms of t-shirt size (say, S-XL). At the next level, work is estimated in the prouct backlog on PBIs. These PBI estimates may be made at the onset of product development and then during planning meetings called by the product owner in a sprint. The metric used here is story points or ideal days. These quantities represent the relative size of one PBI to another in terms of work required. A benefit of having these is the discussion they generate at the meeting when asking the team to put a number on work required. The final level of planning happens at the task level, where the team breaks up the work into number of effort-hours required for tasks within each PBI. These hours aren't actual elapsed hours, however.

What are the three Cs in detail?

Card: On one side of the card, a user story is written in the format "As a <user_type>, I want to <goal> so that <benefit>." It is a placeholder for a more detailed conversation about this goal in the future. Conversation: The conversation(s) which take place because of a card should be tailored to clarify the requirements of the user story. These conversations may reference articles, produce sketches, etc. Confirmation: Each user story will have some confirmation reqs (conditions of satisfaction) . These might be written on the back of the 3x5 card from earlier. These enable a testing team to automate these higher-level tests. This is someitmes called acceptance-test-driven-development.

How do we handle change?

Change is embraced in an economically sensible way throughout development.

How do scrum requirements differ from traditional product dev requirements?

Details of requirements are negotiated through conversation throughout development just enough for teams to build and just in time. Scrum views requirements as weighted, dynamic, manipulatable business goals, such that low-value reqs can be dropped if needed. Scrum treats PBIs as broad, high-value requirements which get refined and detailed over time. Many teams represent their PBIs as user stories or use cases.

What other rules should we follow while servicing technical debt?

Don't service all technical debt: if the product is near the end of lifespan, has a very short lifespan, or is a throwaway prototype it doesn't make much economic sense to invest in eliminating technical debt. Use the boyscout rule to a certain threshold: clean up the development environment (i.e. bad practices, etc.). Repay debt incrementally (not all-in-one sprint), repay debt in areas in which we're giving new value, and repay high-interest debt first (e.g. components which are frequently used and have a lot of dependencies).

What happens during sprint execution (& daily scrum)?

During sprint execution, the dev. team, led by scrum master, completes all task-level work necessary to finish the sprint backlog. At the daily scrum, where pigs (essential members) and chickens (non-essential) may attend, the pigs stand and answer three questions about standing of current development. From there, a team may gather after to further discuss issues brought up

What happens during sprint retrospective?

During sprint retrospective, the scrum team reviews the scrum process itself, analyzing inefficiencies in the process and what should be ammended for the next sprint. Team answers what is and isn't working from the scrum process.

What happens during sprint review?

During sprint review, the product development is analyzed and adapted between the scrum team and non-scrum members. This is a chance for the scrum team to see other sides of the dev (i.e. business & marketing) and vice-versa.

How to user stories come into existence?

Either through user-story-writing workshops or story mapping, user stories can be created at the time of high-level (release level) planning.

What is the difference between exploration and exploitation?

Exploration buys more information through research or prototyping; exploitation uses what is known in the beginning and assumes what isn't.

How can we make technical debt visible to both technical and business people?

For business people, we can make technical debt visible by, say, tracking the velocity over time of the scrum team. As velocity slows, if we assume it is largely due to technical debt, we can see the ramifications of the technical debt by calculating the cost of development at the slower velocity compared to the normal velocity. Aditionally, to make the technical debt visible at the technical level, we may [1] use existing defect tracking software [2] add technical debt entries to the product backlog or [3] keep a tech debt backlog in plain site, next to the product backlog board, so that technical debt is visible during sprint planning.

What is forecasting velocity and when is it needed?

Forecasting velocity occurs when a team has never worked together before. In this case, it is necessary to forecast the velocity of the team by having them plan a sprint (ideally 2 sprints) and using these as a high and low to calculate a forecasted velocity range for the team. Of course, once a sprint happens, throw out the forecast and use the experimental data.

What does the product owner do?

He is both a business analyst and a product tester, ensuring that high-level tests for products are passed (e.g. should work in all major browsers, plus IE 8 & 9).

Who does the product grooming?

In the end, the product owner is responsible for product grooming. That being said, good scrum implies the product owner includes internal/external stakeholders, the scrum master, and the development team too, along the way. This leverages combined intelligence as well as bridging the business/technical gap and streamlining everyone's understanding of requirements.

What is the dev. team responsible for?

It is a diverse and cross-functional collection of people with different skills who design, build, and test the desired product.

How similar is development seen to manufacturing?

It is relatively dissimilar in the fact that it is not a well-defined, rigid process for which all variables are known in the beginning. Development creates a recipe for a unique product.

Who is the Powner?

It varies: where/for whom is the product being developed need be assessed. If internally developed product, Powner is an empowered person from group receiving the benefit. If commercial development, Powner is an empowered person inside the op (in the compnay) who acts as a voice for customers/users. If outsourced dev, the Powner is a rep from the company paying/receiving value. If component team, the Powner is technical person who can balance the PB.

What is the process structure?

Iterative (each sprint builds/learns from the last) and incremental (new features/fixes/improvements delivered) development.

Why keep "normal" sprints (i.e. typical circumstances surround the sprint) at same length?

Keeping sprints at a fixed length reduces overhead and allows the scrum team to achieve a development cadence.

What is the definition of ready?

Like the definition of done, the definition of ready is a threshold for a PBI before it can pass into the "ready" state (ready to be executed). This may be in the form of a checklist which applies to all PBIs before they can be considered ready to be executed during a sprint.

What responsibilities does the product owner have?

Manage economics: PB level (re-prioritize PBIs in light of new information) sprint level (make sure each sprint returns good features for the money) release level (make business decisions regarding when to do a release, if future sprints will continue, how a release should change in light of new info) Planning: plan at the portfolio-, product-, release-, and sprint- level with others (stakeholders, dev. team) on what to build, etc. Grooming: ensure that grooming is done smoothly, delegate work where needed (e.g. size estimation to dev team), and maintain a good PB Define Acceptance Criteria//make sure they're met: Acceptance criteria which need be met for a PBI to be "done" are defined (and possibly tests developed), and the Powner may run tests himself Constant collaboration: A Powner should constantly be collaborating with the dev team (answering questions, etc.) to ensure a good feature is being pushed out within each sprint. Get Input from stakeholders: The Powner is the sole voice of the entire stakeholder community, internal and external. He thus gathers input from all stakeholders (or delegates some of this) and synthesizes a vision for developing features.

How is progress measured?

Measured by validating working assets in increments.

How much formality is employed?

Minimully sufficient for the product.

How/when are multiple Powners appropriate?

Multiple Powners are appropriate when either (a) the commitments are too many for one person (a team is afforded the Powner, but Powner is ultimate authority), (b) the Power spends a lot of time away from the dev team (at meetings, etc), so there is a Powner proxy who makes decisions when Powner is gone, but is not real Powner (or ultimate source of auth), (c ) there are many, many people in the dev effort (10s to 100s to 1000s). Powner hierarchy may be setup, but there are mutliple lines of Powners overseeing multiple individual teams, leading up to a chief Powner.

How are nonfunctional requirements added and what are they?

Nonfunctional requirements are system-level reqs (e.g. works in IE, chrome, and FF on latest version). It is nice to add as many of these as possible into the definition of done for all stories developed, this way fast feedback is maintained.

if one team wants to develop multiple products (with, incidentally, multiple PB stacks), how should the team go about doing this?

One team can develop multiple products (with multiple PBs) in a few different ways. First, if possible, the team could split into subteams, assiging one or more subteams to each PB stack. Second, if possible, the team could work on one PB stack per sprint. Third, if possible, the team could work in parallel on one PB stack which is an amalgamation of the multiple PB stacks throughout the sprint if absolutely necessary; however, the team should still work on one set of PBIs at a time. This also means that the product owner will have to combine the separate PB stacks for each product into one PB stack, which may require more time.

How is decision making handled?

Options are kept open, so an original plan doesn't get in the way of the right answer which may emerge later.

What is planning poker?

Planning poker is a way of coming up with PBI estimates, while motivating a lively discussion by team members to expose assumptions/misunderstandings about a PBI and come up with a consensus of how a PBI should be sized up.

How does one play the game of planning poker?

Planning poker is played by giving all development team members cards with numbers from the domain mentioned above, as well as a "?" card and a special card. A product owner reads a PBI and the team then clarifies the PBI reqs with the product owner. Once this is done, all members estimate the weight of the PBI using a card and expose the card to other members at the same time. If there is consensus, we stop, else a discussion is held and the process is repeated (showing cards) until consensus is reached. Note, a consensus must be reached on a number within the deck...there is no average or in between. The "?" card is a request for clarification or statement of incompetency in this area and the special card signals "I'm done; I want a break/food!".

What is the estimation domain (of numbers) of a PBI?

Rather than a continuous (e.g. 1-100) range, typically a set of a like-fibonacci sequance is used (½, 1, 2, 3, 5, 8, 13, 20, 40, 100..) or a set of powers of two (1, 2, 4, 8, ..). The point of doing this is to emphasize accuracy of rel size estimates over precision.

How is predictive and adaptive work balanced?

Some predictive work is done up front with some just-in-time adaptive work coming in later.

At what level of detail are user stoires produced?

Stories are produced at multiple levels of detail, and doins so is useful for planning at mutiple abstraction levels and to progressively refine big items into small items over time.

What are the two metrics used (by most teams) to estimate the size of a PBI?

Story points and ideal days. These can easily be explained by analogy. Story points is akin to saying "relative development effort points" or "relative dev time points", and it takes into account the physical size of the finished product along with the complexity of developing it; these "points" are relative to the points associated to other PBIs. Ideal days, on the other hand, is used like quarters of a football game. A football game is played in 1 ideal hour, but 3-4 real hours, because of timeouts, interruptions, etc. Ideal days work in much the same way: what takes 1 ideal day (8 man-hours of focused, uninterrupted development) might be 3 real days for a development team.

What are the causes of strategic and naive tech debt?

Strategic and naive debt are the product mainly of the effects of pressuring a team to meet a deadline by falsely accelerating velocity. Presuring a team to meet a deadline off pace the actual projected deadline (determined with the actual velocity) causes a team to deliberately cut corners to meet deadlines. This "falsely accelerates" the velocity of the team. In future releases and sprints, the team has to build atop an already debt-ridden product, further increasing the need to falsely accelerate velocity, and the cycle continues.

What is technical debt and what are the 3 main types of this debt?

Technical debt has evolved to generically refer to any shortcuts taken or bad practices that exist within a software system. The 3 main categories of this debt are naive debt, unavoidable debt, and strategic debt. Naive debt refers to bad design, implementation or business decisions which occur due to bad practices, training, etc. and could be avoided with appropriate training, smart decisions, etc. Unavoidable debt is debt which may be predictable but is unavoidable by virtue of the way things are; an example is using a 3rd party component in an application means that eventually we will have to modify our app when the 3rd party component changes (this is highly predictable, but unavoidable). Finally, strategic debt is technical debt we take on for a reason of economics/business. One example is if a self-funded company is running out of money, it may be best to get a slightly-flawed product out to the market early and gain money to further development.

What are the 4 essential concepts of PBI estimation in scrum? Briefly explain each.

The 4 essential concepts of PBI estimation in scrum are estimate as a team, estimates are not commitments, estimate with accuracy over precision, and use relative sizes when estimating. I'll breifly explain each. Estimate as a team: the people who do the dev work, the development team, estimate the PBIs in the presence of the product owner (there for clarification) and the scrum master (there to guide the process). Estimates are not commitments: Enforcing estimates as commitments would mean artificially inflating the size of the dev team's estimates; the only way to get honesty from the dev team is to allow some leeway for estimation in error. Estimate with high accuracy/low precision: this is common sense...estimating with high precision is likely to cause unneccessary effort and bad estimates; whereas, estimating with low precision allows a roughly right estimate. Use relative sizes when estimating: Plain and simple, it's much harder to size up things in absolute terms versus relative terms (for humans); let humans do what they're good at.

How is the PB managed for good flow in releases as well as sprints?

The PB is managed for good releases by separating the PB into 3 partitions of PBIs: must-haves, nice-to-haves, and will-not-haves (for specific release). For good flow in sprints, the PB must have a certain number of ready-to-go (detailed, testable, understood) items which it can pop off the stack. For most teams, a good rule of thumb is to use 3x the amount of PBIs that they normally accomplish in one sprint.

Why prioritized?

The PBIs should be prioritized, because we want to work on the most critical/desirable components of our application that we can at the time. For this reason, the product backlog must be kept in a prioritized state. As with estimation, we probably won't waste time estimating anywhere past the first release, because we may never build that stuff, or that stuff may change, who knows this soon?

What is the definition of done?

The definition of done is a checklist of things to be accomplished for work done during a sprint to be declared potentially shippable. This should be robust enough to give the dev team high confidence that what it produced is "potentially shippable" and doesn't carry technical debt.

What happens in sprint planning?

The dev. team selects a certain number of PBIs to be implemented in the sprint from the product backlog, breaks these down into tasks, and time appraises these tasks. Ideally, the dev. time will be able to dev. at a comfortable pace and push out all the features selected. A time appraisal (in hours) of each item selected off the product backlog is performed, and while time remains (hours available), more product backlog features are selected and planned. Planning takes usually 8 or less hours, depending on sprint length.

Why detailed appropriately?

The product backlog (items) must be detailed appropriately at the right times. If the product backlog items are all detailed up front, we may be wasting time on features we never develop. If the PBIs are detailed too late, we're slowing down the team. Thus, we want to break down large stories just-in-time (low in the backlog), say, right before a sprint (when they rise in the backlog).

Why emergent?

The product backlog is dynamic. The product owner is responsible for taking changes into account after the sprints and adding or deleting items from the backlog as new information emerges. As new info emerges, so should items on the product backlog and the product owner needs to rebalance the PB.

What are the roles of the scrum master?

The scrum master is a... coach - help the Powner and dev team use scrum effectively, and get the Powner to get the most business value from scrum servant leader - The scrum master leads the team by serving the team in making them more effective process authority - sm is an authority on the scrum process the team uses. She is the person who makes sure work is getting done in an efficient way Interference shield - sm is responsible for keeping dev team delivering value and questioning/blocking interference from other sources (managers, other teams, etc.) remove impediments which block the dev team (and the dev team can't remove themselves) scrum helps change minds and answer questions where people are hesitant to make scrum-like changes

What are user stories?

They are a convenient, brief representation of the business value of a PBI. These user stories are good for many PBIs, but may not be good for all (e.g. fixing defects). They may follow the format of the 3 Cs (Card, Conversation, Confirmation).

Why make sprints short duration?

This ensures ease of planning, fast feedback, bounded error, improved return on investment, rejuvenated excitement in the project, and frequent checkpoints that matter.

What characteristics/skills should a good sm have?

This is a good starter list: knowledgeable (about scrum) questioning (why practices are done) patient (asking probing questions rather than providing answers) collaborative (able to work with Powner, dev team, and other parties as necessry) protective (of the team, making sure that all members are and stay comitted) transparent communication (without a hidden agenda)

What is the product backlog?

This is a groomed (read: prioritized or ordered) set of features, bug fixes, improvements, etc. which is created and prioritized by the product owner, who does research with stakeholders to gather backlog items. The size of these items is ranked on a relative scale in story points (i.e. relative to other items on the list with knowledge of past products), and it is detailed more over time.

When has a potentially shippable product been created (considered "done")?

This is defined as the dev. team has completed all the work it agreed to in sprint planning. It increases the confidence that the work completed is of good-quality and potentially shippable (i.e. no desiging, building, or testing of these features is left undone).

What does potentially shippable mean?

This means the team is in a state of confidence that what got done during the sprint is actually done. For example, features are tested and integrated fully, and if business wants to ship, it can ship.

Why is it good to NOT make goal-altering changes during a sprint?

This voids a mutual agreement between dev team (will get agreed upon work done within timebox of sprint) and product owner (will not make goal altering changes to this work).

Why is it a bad idea to reward separate teams based on velocity?

This will likely just cause a team to get smart and "inflate" its point system so that they just increase the relative values of what each PBI becomes in terms of points.

When does grooming take place?

To an extent, grooming will take place during sprint planning, sprint review, and sprint retrospective. However, additional grooming typically takes place throughout the sprint (e.g. after daily scrum, at scheduled "grooming" time in week, or ad hoc).

How do we manage tech debt?

To manage tech debt, a balanced business/tech discussion must be held. There are three ways to effectively manage technical debt throughout the development process. [1] Manage the accrual of this debt [2] make the debt visible when it exists [3] repay the debt (service the product)

How is uncertainty managed?

Uncertainty is managed by reducing all uncertainties simultaneously (reduce the whats and hows)

Why use conversations instead of traditional written requirements?

Using dynamic conversation to generate just-in-time requirements at a detailed-level is more effective than static, up-front writing.

What's the benefit of using progressive refinement for requirements?

Using progressive refinement, to define the details of broader requirements throughout the development process is more adaptable to change and economically efficient.

How is velocity affected over time?

Velocity improves over time for a good scrum team, as they are constantly improving, to a point. At this point, a plateau has been hit, and bigger changes may need to be made to keep improving velocity (newer tools, training, environment, staff, etc). These changes are usually met with slight dip in productivity followed by an increase.

What is velocity? what is its purpose?

Velocity is a measure of how much a scrum team accomplishes over time. It's measured in dividing story points or ideal days per sprint. (note: only fully accomplished PBIs count) The purpose of velocity is twofold: [1] a metric useful for planning what the team can realistically get done [2] an metric for internal team improvement.

What is assumed about getting it right the first time?

We assume we cannot get things right up front.

How can a product be developed with multiple component teams working on each feature of the product?

We can have one huge product backlog which encapsulates the 10,000 ft view of the product with very large-scale features. From there, area backlogs would be kept for separate area teams. For example, in creating the android OS, an area team might exist for the phone application, another for the browser, yet another for the menu and settings, etc, but all the high-level featuers exist in a master product backlog. These are managed by a chief product owner. Another method is to use the many teams to one PB approach. In this case, each area team would look only at parts of the backlog containing PBIs which it prefers to do next (if teams aren't interchangeable). If teams are interchangeable, obviously teams could just pop the next high-priority item off the PB stack.

How can we evaluate our product backlog?

We use the acronym DEEP: Detailed appropriately, Emergent, Estimated, and Prioritized.

Why estimated?

We want to estimate more detailed items as they rise in the product backlog and become near sprint-ready. Estimating is a key component in determining the priority of a PBI. Thus, we need to estimate the priority of PBIs high in the PB. On the other hand, we don't want to waste time estimating anywhere past the next release. So only the items planned for the next release will be estimated (in story points/ideal days) in most cases, and others may be estimated more relatively, like in t-shirt sizes.

How do we know if stories are structured well?

Well defined stories follow an acronym : INVEST (independt, negotiable, valuable, estimatable, sized appropriately (small), testable).

How fast is feedback given?

Workflow is organized around getting fast feedback.

How do we service our technical debt?

[1] Decide if we want to repay the technical debt. [2] Repay debt as-it's-found to a reasonable time threshold [3] Every sprint, consider designating a certain amount of time to eliminating some known high-interest technical debt, in the areas in which we're already working.

How are assumptions made?

assumptions are validated (either as correct or incorrect) early and often through tight feedback loops.

How does acceptance criteria (conditions of satisfaction) differ from done-criteria?

done-criteria is more general, applying to all PBIs for the sprint, whereas acceptance criteria is more specific, having acceptance criteria specific to each PBI.

How is feedback handled?

feedback happens in multiple concurrent learning loops (daily in daily scrum; after each sprint; etc)