Scrum

Scrum is a frame­work for de­vel­op­ing, de­liv­er­ing, and sus­tain­ing com­plex prod­ucts. Scrum is a process frame­work that has been used to man­age work on com­plex prod­ucts since the ear­ly 1990s. Scrum is not a process, tech­nique, or de­fin­i­tive method. Rather, it is a frame­work with­in which you can em­ploy var­i­ous process­es and tech­niques. Scrum makes clear the rel­a­tive ef­fi­ca­cy of your prod­uct man­age­ment and work tech­niques so that you can con­tin­u­ous­ly im­prove the prod­uct, the team, and the work­ing environment.The Scrum frame­work con­sists of Scrum Teams and their as­so­ci­at­ed roles, events, ar­ti­facts, and rules. Each com­po­nent with­in the frame­work serves a spe­cif­ic pur­pose and is es­sen­tial to Scrum’s suc­cess and usage.

Scrum Framework

How Scrum embraces empiricism

Scrum is found­ed on em­pir­i­cal process con­trol the­o­ry or em­piri­cism. Em­piri­cism as­serts that knowl­edge comes from ex­pe­ri­ence and mak­ing de­ci­sions based on what is known. Scrum em­ploys an it­er­a­tive, in­cre­men­tal ap­proach to op­ti­mize pre­dictabil­i­ty and con­trol risk. Three pil­lars up­hold every im­ple­men­ta­tion of em­pir­i­cal process con­trol: trans­paren­cy, in­spec­tion, and adaptation.

Transparency

Sig­nif­i­cant as­pects of the process must be vis­i­ble to those re­spon­si­ble for the out­come. Trans­paren­cy re­quires those as­pects be de­fined by a com­mon stan­dard so ob­servers share a com­mon un­der­stand­ing of what is be­ing seen.

For ex­am­ple:

  • A com­mon lan­guage re­fer­ring to the process must be shared by all par­tic­i­pants; and,
  • Those per­form­ing the work and those in­spect­ing the re­sult­ing in­cre­ment must share a com­mon de­f­i­n­i­tion of “Done”.

Inspection

Scrum users must fre­quent­ly in­spect Scrum ar­ti­facts and progress to­ward a Sprint Goal to de­tect un­de­sir­able vari­ances. Their in­spec­tion should not be so fre­quent that in­spec­tion gets in the way of the work. In­spec­tions are most ben­e­fi­cial when dili­gent­ly per­formed by skilled in­spec­tors at the point of work.

Adaptation

If an in­spec­tor de­ter­mines that one or more as­pects of a process de­vi­ate out­side ac­cept­able lim­its, and that the re­sult­ing prod­uct will be un­ac­cept­able, the process or the ma­te­r­i­al be­ing processed must be ad­just­ed. An ad­just­ment must be made as soon as pos­si­ble to min­i­mize fur­ther deviation.

Scrum pre­scribes four for­mal events for in­spec­tion and adap­ta­tion, as de­scribed in the Scrum Events sec­tion of this document:

  • Sprint Plan­ning
  • Dai­ly Scrum
  • Sprint Re­view
  • Sprint Ret­ro­spec­tive

Scrum Values

When the val­ues of com­mit­ment, courage, fo­cus, open­ness, and re­spect are em­bod­ied and lived by the Scrum Team, the Scrum pil­lars of trans­paren­cy, in­spec­tion, and adap­ta­tion come to life and build trust for every­one. The Scrum Team mem­bers learn and ex­plore those val­ues as they work with the Scrum events, roles, and artifacts.

Suc­cess­ful use of Scrum de­pends on peo­ple be­com­ing more pro­fi­cient in liv­ing these five val­ues. Peo­ple per­son­al­ly com­mit to achiev­ing the goals of the Scrum Team. The Scrum Team mem­bers have the courage to do the right thing and work on tough prob­lems. Every­one fo­cus­es on the work of the Sprint and the goals of the Scrum Team. The Scrum Team and its stake­hold­ers agree to be open about all the work and the chal­lenges with per­form­ing the work. Scrum Team mem­bers re­spect each oth­er to be ca­pa­ble, in­de­pen­dent people.

The Scrum Team

The Scrum Team con­sists of a Prod­uct Own­er, the De­vel­op­ment Team, and a Scrum Mas­ter. Scrum Teams are self-or­ga­niz­ing and cross-func­tion­al. Self-or­ga­niz­ing teams choose how best to ac­com­plish their work, rather than be­ing di­rect­ed by oth­ers out­side the team. Cross-func­tion­al teams have all com­pe­ten­cies need­ed to ac­com­plish the work with­out de­pend­ing on oth­ers not part of the team. The team mod­el in Scrum is de­signed to op­ti­mize flex­i­bil­i­ty, cre­ativ­i­ty, and pro­duc­tiv­i­ty. The Scrum Team has proven it­self to be in­creas­ing­ly ef­fec­tive for all the ear­li­er stat­ed uses, and any com­plex work.

Scrum Teams de­liv­er prod­ucts it­er­a­tive­ly and in­cre­men­tal­ly, max­i­miz­ing op­por­tu­ni­ties for feed­back. In­cre­men­tal de­liv­er­ies of “Done” prod­uct en­sure a po­ten­tial­ly use­ful ver­sion of work­ing prod­uct is al­ways available.

The Product Owner

The Prod­uct Own­er is re­spon­si­ble for max­i­miz­ing the val­ue of the prod­uct re­sult­ing from work of the De­vel­op­ment Team. How this is done may vary wide­ly across or­ga­ni­za­tions, Scrum Teams, and individuals.

The Prod­uct Own­er is the sole per­son re­spon­si­ble for man­ag­ing the Prod­uct Back­log. Prod­uct Back­log man­age­ment includes:

  • Clear­ly ex­press­ing Prod­uct Back­log items;
  • Or­der­ing the items in the Prod­uct Back­log to best achieve goals and missions;
  • Op­ti­miz­ing the val­ue of the work the De­vel­op­ment Team performs;
  • En­sur­ing that the Prod­uct Back­log is vis­i­ble, trans­par­ent, and clear to all, and shows what the Scrum Team will work on next; and,
  • En­sur­ing the De­vel­op­ment Team un­der­stands items in the Prod­uct Back­log to the lev­el needed.

The Prod­uct Own­er may do the above work, or have the De­vel­op­ment Team do it. How­ev­er, the Prod­uct Own­er re­mains accountable.

The Prod­uct Own­er is one per­son, not a com­mit­tee. The Prod­uct Own­er may rep­re­sent the de­sires of a com­mit­tee in the Prod­uct Back­log, but those want­i­ng to change a Prod­uct Back­log item’s pri­or­i­ty must ad­dress the Prod­uct Owner.

For the Prod­uct Own­er to suc­ceed, the en­tire or­ga­ni­za­tion must re­spect his or her de­ci­sions. The Prod­uct Owner’s de­ci­sions are vis­i­ble in the con­tent and or­der­ing of the Prod­uct Back­log. No one can force the De­vel­op­ment Team to work from a dif­fer­ent set of requirements.

The Development Team

The De­vel­op­ment Team con­sists of pro­fes­sion­als who do the work of de­liv­er­ing a po­ten­tial­ly re­leasable In­cre­ment of “Done” prod­uct at the end of each Sprint. A “Done” in­cre­ment is re­quired at the Sprint Re­view. Only mem­bers of the De­vel­op­ment Team cre­ate the Increment.

De­vel­op­ment Teams are struc­tured and em­pow­ered by the or­ga­ni­za­tion to or­ga­nize and man­age their own work. The re­sult­ing syn­er­gy op­ti­mizes the De­vel­op­ment Team’s over­all ef­fi­cien­cy and effectiveness.

De­vel­op­ment Teams have the fol­low­ing characteristics:

  • They are self-or­ga­niz­ing. No one (not even the Scrum Mas­ter) tells the De­vel­op­ment Team how to turn Prod­uct Back­log into In­cre­ments of po­ten­tial­ly re­leasable functionality;
  • De­vel­op­ment Teams are cross-func­tion­al, with all the skills as a team nec­es­sary to cre­ate a prod­uct Increment;
  • Scrum rec­og­nizes no ti­tles for De­vel­op­ment Team mem­bers, re­gard­less of the work be­ing per­formed by the person;
  • Scrum rec­og­nizes no sub-teams in the De­vel­op­ment Team, re­gard­less of do­mains that need to be ad­dressed like test­ing, ar­chi­tec­ture, op­er­a­tions, or busi­ness analy­sis; and,
  • In­di­vid­ual De­vel­op­ment Team mem­bers may have spe­cial­ized skills and ar­eas of fo­cus, but ac­count­abil­i­ty be­longs to the De­vel­op­ment Team as a whole.

The Scrum Master

The Scrum Mas­ter is re­spon­si­ble for pro­mot­ing and sup­port­ing Scrum as de­fined in the Scrum Guide. Scrum Mas­ters do this by help­ing every­one un­der­stand Scrum the­o­ry, prac­tices, rules, and values.

The Scrum Mas­ter is a ser­vant-leader for the Scrum Team. The Scrum Mas­ter helps those out­side the Scrum Team un­der­stand which of their in­ter­ac­tions with the Scrum Team are help­ful and which aren’t. The Scrum Mas­ter helps every­one change these in­ter­ac­tions to max­i­mize the val­ue cre­at­ed by the Scrum Team.

Scrum Master Service to the Product Owner

The Scrum Mas­ter serves the Prod­uct Own­er in sev­er­al ways, including:

  • En­sur­ing that goal, scope, and prod­uct do­main are un­der­stood by every­one on the Scrum Team as well as possible;
  • Find­ing tech­niques for ef­fec­tive Prod­uct Back­log management;
  • Help­ing the Scrum Team un­der­stand the need for clear and con­cise Prod­uct Back­log items;
  • Un­der­stand­ing prod­uct plan­ning in an em­pir­i­cal environment;
  • En­sur­ing the Prod­uct Own­er knows how to arrange the Prod­uct Back­log to max­i­mize value;
  • Un­der­stand­ing and prac­tic­ing agili­ty; and,
  • Fa­cil­i­tat­ing Scrum events as re­quest­ed or needed.

Scrum Events

Pre­scribed events are used in Scrum to cre­ate reg­u­lar­i­ty and to min­i­mize the need for meet­ings not de­fined in Scrum. All events are time-boxed events, such that every event has a max­i­mum du­ra­tion. Once a Sprint be­gins, its du­ra­tion is fixed and can­not be short­ened or length­ened. The re­main­ing events may end when­ev­er the pur­pose of the event is achieved, en­sur­ing an ap­pro­pri­ate amount of time is spent with­out al­low­ing waste in the process.

Oth­er than the Sprint it­self, which is a con­tain­er for all oth­er events, each event in Scrum is a for­mal op­por­tu­ni­ty to in­spect and adapt some­thing. These events are specif­i­cal­ly de­signed to en­able crit­i­cal trans­paren­cy and in­spec­tion. Fail­ure to in­clude any of these events re­sults in re­duced trans­paren­cy and is a lost op­por­tu­ni­ty to in­spect and adapt.

The Sprint

The heart of Scrum is a Sprint, a time-box of one month or less dur­ing which a “Done”, use­able, and po­ten­tial­ly re­leasable prod­uct In­cre­ment is cre­at­ed. Sprints have con­sis­tent du­ra­tions through­out a de­vel­op­ment ef­fort. A new Sprint starts im­me­di­ate­ly af­ter the con­clu­sion of the pre­vi­ous Sprint.

Sprints con­tain and con­sist of the Sprint Plan­ning, Dai­ly Scrums, the de­vel­op­ment work, the Sprint Re­view, and the Sprint Retrospective.

Dur­ing the Sprint:

  • No changes are made that would en­dan­ger the Sprint Goal;
  • Qual­i­ty goals do not de­crease; and,
  • Scope may be clar­i­fied and re-ne­go­ti­at­ed be­tween the Prod­uct Own­er and De­vel­op­ment Team as more is learned.

Each Sprint may be con­sid­ered a project with no more than a one-month hori­zon. Like projects, Sprints are used to ac­com­plish some­thing. Each Sprint has a goal of what is to be built, a de­sign and flex­i­ble plan that will guide build­ing it, the work, and the re­sul­tant prod­uct increment.

Sprints are lim­it­ed to one cal­en­dar month. When a Sprint’s hori­zon is too long the de­f­i­n­i­tion of what is be­ing built may change, com­plex­i­ty may rise, and risk may in­crease. Sprints en­able pre­dictabil­i­ty by en­sur­ing in­spec­tion and adap­ta­tion of progress to­ward a Sprint Goal at least every cal­en­dar month. Sprints also lim­it risk to one cal­en­dar month of cost.

Sprint Planning

The work to be per­formed in the Sprint is planned at the Sprint Plan­ning. This plan is cre­at­ed by the col­lab­o­ra­tive work of the en­tire Scrum Team.

Sprint Plan­ning is time-boxed to a max­i­mum of eight hours for a one-month Sprint. For short­er Sprints, the event is usu­al­ly short­er. The Scrum Mas­ter en­sures that the event takes place and that at­ten­dants un­der­stand its pur­pose. The Scrum Mas­ter teach­es the Scrum Team to keep it with­in the time-box.

Sprint Plan­ning an­swers the following:

  • What can be de­liv­ered in the In­cre­ment re­sult­ing from the up­com­ing Sprint?
  • How will the work need­ed to de­liv­er the In­cre­ment be achieved?

Topic One: What can be done this Sprint?

The De­vel­op­ment Team works to fore­cast the func­tion­al­i­ty that will be de­vel­oped dur­ing the Sprint. The Prod­uct Own­er dis­cuss­es the ob­jec­tive that the Sprint should achieve and the Prod­uct Back­log items that, if com­plet­ed in the Sprint, would achieve the Sprint Goal. The en­tire Scrum Team col­lab­o­rates on un­der­stand­ing the work of the Sprint.

The in­put to this meet­ing is the Prod­uct Back­log, the lat­est prod­uct In­cre­ment, pro­ject­ed ca­pac­i­ty of the De­vel­op­ment Team dur­ing the Sprint, and past per­for­mance of the De­vel­op­ment Team. The num­ber of items se­lect­ed from the Prod­uct Back­log for the Sprint is sole­ly up to the De­vel­op­ment Team. Only the De­vel­op­ment Team can as­sess what it can ac­com­plish over the up­com­ing Sprint.

Dur­ing Sprint Plan­ning the Scrum Team also crafts a Sprint Goal. The Sprint Goal is an ob­jec­tive that will be met with­in the Sprint through the im­ple­men­ta­tion of the Prod­uct Back­log, and it pro­vides guid­ance to the De­vel­op­ment Team on why it is build­ing the Increment.

Topic Two: how will the chosen work get done?

Hav­ing set the Sprint Goal and se­lect­ed the Prod­uct Back­log items for the Sprint, the De­vel­op­ment Team de­cides how it will build this func­tion­al­i­ty into a “Done” prod­uct In­cre­ment dur­ing the Sprint. The Prod­uct Back­log items se­lect­ed for this Sprint plus the plan for de­liv­er­ing them is called the Sprint Backlog.

The De­vel­op­ment Team usu­al­ly starts by de­sign­ing the sys­tem and the work need­ed to con­vert the Prod­uct Back­log into a work­ing prod­uct In­cre­ment. Work may be of vary­ing size, or es­ti­mat­ed ef­fort. How­ev­er, enough work is planned dur­ing Sprint Plan­ning for the De­vel­op­ment Team to fore­cast what it be­lieves it can do in the up­com­ing Sprint. Work planned for the first days of the Sprint by the De­vel­op­ment Team is de­com­posed by the end of this meet­ing, of­ten to units of one day or less. The De­vel­op­ment Team self-or­ga­nizes to un­der­take the work in the Sprint Back­log, both dur­ing Sprint Plan­ning and as need­ed through­out the Sprint.

The Prod­uct Own­er can help to clar­i­fy the se­lect­ed Prod­uct Back­log items and make trade-offs. If the De­vel­op­ment Team de­ter­mines it has too much or too lit­tle work, it may rene­go­ti­ate the se­lect­ed Prod­uct Back­log items with the Prod­uct Own­er. The De­vel­op­ment Team may also in­vite oth­er peo­ple to at­tend to pro­vide tech­ni­cal or do­main advice.

By the end of the Sprint Plan­ning, the De­vel­op­ment Team should be able to ex­plain to the Prod­uct Own­er and Scrum Mas­ter how it in­tends to work as a self-or­ga­niz­ing team to ac­com­plish the Sprint Goal and cre­ate the an­tic­i­pat­ed Increment.

Sprint Goal

The Sprint Goal is an ob­jec­tive set for the Sprint that can be met through the im­ple­men­ta­tion of Prod­uct Back­log. It pro­vides guid­ance to the De­vel­op­ment Team on why it is build­ing the In­cre­ment. It is cre­at­ed dur­ing the Sprint Plan­ning meet­ing. The Sprint Goal gives the De­vel­op­ment Team some flex­i­bil­i­ty re­gard­ing the func­tion­al­i­ty im­ple­ment­ed with­in the Sprint. The se­lect­ed Prod­uct Back­log items de­liv­er one co­her­ent func­tion, which can be the Sprint Goal. The Sprint Goal can be any oth­er co­her­ence that caus­es the De­vel­op­ment Team to work to­geth­er rather than on sep­a­rate initiatives.

As the De­vel­op­ment Team works, it keeps the Sprint Goal in mind. In or­der to sat­is­fy the Sprint Goal, it im­ple­ments func­tion­al­i­ty and tech­nol­o­gy. If the work turns out to be dif­fer­ent than the De­vel­op­ment Team ex­pect­ed, they col­lab­o­rate with the Prod­uct Own­er to ne­go­ti­ate the scope of Sprint Back­log with­in the Sprint.

Daily Scrum

The Dai­ly Scrum is a 15-minute time-boxed event for the De­vel­op­ment Team. The Dai­ly Scrum is held every day of the Sprint. At it, the De­vel­op­ment Team plans work for the next 24 hours. This op­ti­mizes team col­lab­o­ra­tion and per­for­mance by in­spect­ing the work since the last Dai­ly Scrum and fore­cast­ing up­com­ing Sprint work. The Dai­ly Scrum is held at the same time and place each day to re­duce complexity.

The De­vel­op­ment Team uses the Dai­ly Scrum to in­spect progress to­ward the Sprint Goal and to in­spect how progress is trend­ing to­ward com­plet­ing the work in the Sprint Back­log. The Dai­ly Scrum op­ti­mizes the prob­a­bil­i­ty that the De­vel­op­ment Team will meet the Sprint Goal. Every day, the De­vel­op­ment Team should un­der­stand how it in­tends to work to­geth­er as a self-or­ga­niz­ing team to ac­com­plish the Sprint Goal and cre­ate the an­tic­i­pat­ed In­cre­ment by the end of the Sprint.

The struc­ture of the meet­ing is set by the De­vel­op­ment Team and can be con­duct­ed in dif­fer­ent ways if it fo­cus­es on progress to­ward the Sprint Goal. Some De­vel­op­ment Teams will use ques­tions, some will be more dis­cus­sion based. Here is an ex­am­ple of what might be used:

  • What did I do yes­ter­day that helped the De­vel­op­ment Team meet the Sprint Goal?
  • What will I do to­day to help the De­vel­op­ment Team meet the Sprint Goal?
  • Do I see any im­ped­i­ment that pre­vents me or the De­vel­op­ment Team from meet­ing the Sprint Goal?

The De­vel­op­ment Team or team mem­bers of­ten meet im­me­di­ate­ly af­ter the Dai­ly Scrum for de­tailed dis­cus­sions, or to adapt, or re­plan, the rest of the Sprint’s work.

The Scrum Mas­ter en­sures that the De­vel­op­ment Team has the meet­ing, but the De­vel­op­ment Team is re­spon­si­ble for con­duct­ing the Dai­ly Scrum. The Scrum Mas­ter teach­es the De­vel­op­ment Team to keep the Dai­ly Scrum with­in the 15-minute time-box.

The Dai­ly Scrum is an in­ter­nal meet­ing for the De­vel­op­ment Team. If oth­ers are present, the Scrum Mas­ter en­sures that they do not dis­rupt the meeting.

Dai­ly Scrums im­prove com­mu­ni­ca­tions, elim­i­nate oth­er meet­ings, iden­ti­fy im­ped­i­ments to de­vel­op­ment for re­moval, high­light and pro­mote quick de­ci­sion-mak­ing, and im­prove the De­vel­op­ment Team’s lev­el of knowl­edge. This is a key in­spect and adapt meeting.

Sprint Review

A Sprint Re­view is held at the end of the Sprint to in­spect the In­cre­ment and adapt the Prod­uct Back­log if need­ed. Dur­ing the Sprint Re­view, the Scrum Team and stake­hold­ers col­lab­o­rate about what was done in the Sprint. Based on that and any changes to the Prod­uct Back­log dur­ing the Sprint, at­ten­dees col­lab­o­rate on the next things that could be done to op­ti­mize val­ue. This is an in­for­mal meet­ing, not a sta­tus meet­ing, and the pre­sen­ta­tion of the In­cre­ment is in­tend­ed to elic­it feed­back and fos­ter collaboration.

This is at most a four-hour meet­ing for one-month Sprints. For short­er Sprints, the event is usu­al­ly short­er. The Scrum Mas­ter en­sures that the event takes place and that at­ten­dees un­der­stand its pur­pose. The Scrum Mas­ter teach­es every­one in­volved to keep it with­in the time-box.

The Sprint Re­view in­cludes the fol­low­ing elements:

  • At­ten­dees in­clude the Scrum Team and key stake­hold­ers in­vit­ed by the Prod­uct Owner;
  • The Prod­uct Own­er ex­plains what Prod­uct Back­log items have been “Done” and what has not been “Done”;
  • The De­vel­op­ment Team dis­cuss­es what went well dur­ing the Sprint, what prob­lems it ran into, and how those prob­lems were solved;
  • The De­vel­op­ment Team demon­strates the work that it has “Done” and an­swers ques­tions about the Increment;
  • The Prod­uct Own­er dis­cuss­es the Prod­uct Back­log as it stands. He or she projects like­ly tar­get and de­liv­ery dates based on progress to date (if needed);
  • The en­tire group col­lab­o­rates on what to do next, so that the Sprint Re­view pro­vides valu­able in­put to sub­se­quent Sprint Planning;
  • Re­view of how the mar­ket­place or po­ten­tial use of the prod­uct might have changed what is the most valu­able thing to do next; and,
  • Re­view of the time­line, bud­get, po­ten­tial ca­pa­bil­i­ties, and mar­ket­place for the next an­tic­i­pat­ed re­leas­es of func­tion­al­i­ty or ca­pa­bil­i­ty of the product.

The re­sult of the Sprint Re­view is a re­vised Prod­uct Back­log that de­fines the prob­a­ble Prod­uct Back­log items for the next Sprint. The Prod­uct Back­log may also be ad­just­ed over­all to meet new opportunities.

Sprint Retrospective

The Sprint Ret­ro­spec­tive is an op­por­tu­ni­ty for the Scrum Team to in­spect it­self and cre­ate a plan for im­prove­ments to be en­act­ed dur­ing the next Sprint.

The Sprint Ret­ro­spec­tive oc­curs af­ter the Sprint Re­view and pri­or to the next Sprint Plan­ning. This is at most a three-hour meet­ing for one-month Sprints. For short­er Sprints, the event is usu­al­ly short­er. The Scrum Mas­ter en­sures that the event takes place and that at­ten­dants un­der­stand its purpose.

The Scrum Mas­ter en­sures that the meet­ing is pos­i­tive and pro­duc­tive. The Scrum Mas­ter teach­es all to keep it with­in the time-box. The Scrum Mas­ter par­tic­i­pates as a peer team mem­ber in the meet­ing from the ac­count­abil­i­ty over the Scrum process.

The pur­pose of the Sprint Ret­ro­spec­tive is to:

  • In­spect how the last Sprint went with re­gards to peo­ple, re­la­tion­ships, process, and tools;
  • Iden­ti­fy and or­der the ma­jor items that went well and po­ten­tial im­prove­ments; and,
  • Cre­ate a plan for im­ple­ment­ing im­prove­ments to the way the Scrum Team does its work.

The Scrum Mas­ter en­cour­ages the Scrum Team to im­prove, with­in the Scrum process frame­work, its de­vel­op­ment process and prac­tices to make it more ef­fec­tive and en­joy­able for the next Sprint. Dur­ing each Sprint Ret­ro­spec­tive, the Scrum Team plans ways to in­crease prod­uct qual­i­ty by im­prov­ing work process­es or adapt­ing the de­f­i­n­i­tion of “Done”, if ap­pro­pri­ate and not in con­flict with prod­uct or or­ga­ni­za­tion­al standards.

By the end of the Sprint Ret­ro­spec­tive, the Scrum Team should have iden­ti­fied im­prove­ments that it will im­ple­ment in the next Sprint. Im­ple­ment­ing these im­prove­ments in the next Sprint is the adap­ta­tion to the in­spec­tion of the Scrum Team it­self. Al­though im­prove­ments may be im­ple­ment­ed at any time, the Sprint Ret­ro­spec­tive pro­vides a for­mal op­por­tu­ni­ty to fo­cus on in­spec­tion and adaptation.

Scrum Artifacts

Scrum’s ar­ti­facts rep­re­sent work or val­ue to pro­vide trans­paren­cy and op­por­tu­ni­ties for in­spec­tion and adap­ta­tion. Ar­ti­facts de­fined by Scrum are specif­i­cal­ly de­signed to max­i­mize trans­paren­cy of key in­for­ma­tion so that every­body has the same un­der­stand­ing of the artifact.

Product Backlog

The Prod­uct Back­log is an or­dered list of every­thing that is known to be need­ed in the prod­uct. It is the sin­gle source of re­quire­ments for any changes to be made to the prod­uct. The Prod­uct Own­er is re­spon­si­ble for the Prod­uct Back­log, in­clud­ing its con­tent, avail­abil­i­ty, and ordering.

A Prod­uct Back­log is nev­er com­plete. The ear­li­est de­vel­op­ment of it lays out the ini­tial­ly known and best-un­der­stood re­quire­ments. The Prod­uct Back­log evolves as the prod­uct and the en­vi­ron­ment in which it will be used evolves. The Prod­uct Back­log is dy­nam­ic; it con­stant­ly changes to iden­ti­fy what the prod­uct needs to be ap­pro­pri­ate, com­pet­i­tive, and use­ful. If a prod­uct ex­ists, its Prod­uct Back­log also exists.

The Prod­uct Back­log lists all fea­tures, func­tions, re­quire­ments, en­hance­ments, and fix­es that con­sti­tute the changes to be made to the prod­uct in fu­ture re­leas­es. Prod­uct Back­log items have the at­trib­ut­es of a de­scrip­tion, or­der, es­ti­mate, and val­ue. Prod­uct Back­log items of­ten in­clude test de­scrip­tions that will prove its com­plete­ness when “Done”.

As a prod­uct is used and gains val­ue, and the mar­ket­place pro­vides feed­back, the Prod­uct Back­log be­comes a larg­er and more ex­haus­tive list. Re­quire­ments nev­er stop chang­ing, so a Prod­uct Back­log is a liv­ing ar­ti­fact. Changes in busi­ness re­quire­ments, mar­ket con­di­tions, or tech­nol­o­gy may cause changes in the Prod­uct Backlog.

Mul­ti­ple Scrum Teams of­ten work to­geth­er on the same prod­uct. One Prod­uct Back­log is used to de­scribe the up­com­ing work on the prod­uct. A Prod­uct Back­log at­tribute that groups items may then be employed.

Prod­uct Back­log re­fine­ment is the act of adding de­tail, es­ti­mates, and or­der to items in the Prod­uct Back­log. This is an on­go­ing process in which the Prod­uct Own­er and the De­vel­op­ment Team col­lab­o­rate on the de­tails of Prod­uct Back­log items. Dur­ing Prod­uct Back­log re­fine­ment, items are re­viewed and re­vised. The Scrum Team de­cides how and when re­fine­ment is done. Re­fine­ment usu­al­ly con­sumes no more than 10% of the ca­pac­i­ty of the De­vel­op­ment Team. How­ev­er, Prod­uct Back­log items can be up­dat­ed at any time by the Prod­uct Own­er or at the Prod­uct Owner’s discretion.

High­er or­dered Prod­uct Back­log items are usu­al­ly clear­er and more de­tailed than low­er or­dered ones. More pre­cise es­ti­mates are made based on the greater clar­i­ty and in­creased de­tail; the low­er the or­der, the less de­tail. Prod­uct Back­log items that will oc­cu­py the De­vel­op­ment Team for the up­com­ing Sprint are re­fined so that any one item can rea­son­ably be “Done” with­in the Sprint time-box. Prod­uct Back­log items that can be “Done” by the De­vel­op­ment Team with­in one Sprint are deemed “Ready” for se­lec­tion in a Sprint Plan­ning. Prod­uct Back­log items usu­al­ly ac­quire this de­gree of trans­paren­cy through the above de­scribed re­fin­ing activities.

The De­vel­op­ment Team is re­spon­si­ble for all es­ti­mates. The Prod­uct Own­er may in­flu­ence the De­vel­op­ment Team by help­ing it un­der­stand and se­lect trade-offs, but the peo­ple who will per­form the work make the fi­nal estimate.

Monitoring Progress Toward Goals

At any point in time, the to­tal work re­main­ing to reach a goal can be summed. The Prod­uct Own­er tracks this to­tal work re­main­ing at least every Sprint Re­view. The Prod­uct Own­er com­pares this amount with work re­main­ing at pre­vi­ous Sprint Re­views to as­sess progress to­ward com­plet­ing pro­ject­ed work by the de­sired time for the goal. This in­for­ma­tion is made trans­par­ent to all stakeholders.

Var­i­ous pro­jec­tive prac­tices upon trend­ing have been used to fore­cast progress, like burn-downs, burn-ups, or cu­mu­la­tive flows. These have proven use­ful. How­ev­er, these do not re­place the im­por­tance of em­piri­cism. In com­plex en­vi­ron­ments, what will hap­pen is un­known. Only what has al­ready hap­pened may be used for for­ward-look­ing decision-making.

Sprint Backlog

The Sprint Back­log is the set of Prod­uct Back­log items se­lect­ed for the Sprint, plus a plan for de­liv­er­ing the prod­uct In­cre­ment and re­al­iz­ing the Sprint Goal. The Sprint Back­log is a fore­cast by the De­vel­op­ment Team about what func­tion­al­i­ty will be in the next In­cre­ment and the work need­ed to de­liv­er that func­tion­al­i­ty into a “Done” Increment.

The Sprint Back­log makes vis­i­ble all the work that the De­vel­op­ment Team iden­ti­fies as nec­es­sary to meet the Sprint Goal. To en­sure con­tin­u­ous im­prove­ment, it in­cludes at least one high pri­or­i­ty process im­prove­ment iden­ti­fied in the pre­vi­ous Ret­ro­spec­tive meeting.

The Sprint Back­log is a plan with enough de­tail that changes in progress can be un­der­stood in the Dai­ly Scrum. The De­vel­op­ment Team mod­i­fies the Sprint Back­log through­out the Sprint, and the Sprint Back­log emerges dur­ing the Sprint. This emer­gence oc­curs as the De­vel­op­ment Team works through the plan and learns more about the work need­ed to achieve the Sprint Goal.

As new work is re­quired, the De­vel­op­ment Team adds it to the Sprint Back­log. As work is per­formed or com­plet­ed, the es­ti­mat­ed re­main­ing work is up­dat­ed. When el­e­ments of the plan are deemed un­nec­es­sary, they are re­moved. Only the De­vel­op­ment Team can change its Sprint Back­log dur­ing a Sprint. The Sprint Back­log is a high­ly vis­i­ble, real-time pic­ture of the work that the De­vel­op­ment Team plans to ac­com­plish dur­ing the Sprint, and it be­longs sole­ly to the De­vel­op­ment Team.

Monitoring Sprint Progress

At any point in time in a Sprint, the to­tal work re­main­ing in the Sprint Back­log can be summed. The De­vel­op­ment Team tracks this to­tal work re­main­ing at least for every Dai­ly Scrum to project the like­li­hood of achiev­ing the Sprint Goal. By track­ing the re­main­ing work through­out the Sprint, the De­vel­op­ment Team can man­age its progress.

Increment

The In­cre­ment is the sum of all the Prod­uct Back­log items com­plet­ed dur­ing a Sprint and the val­ue of the in­cre­ments of all pre­vi­ous Sprints. At the end of a Sprint, the new In­cre­ment must be “Done,” which means it must be in use­able con­di­tion and meet the Scrum Team’s de­f­i­n­i­tion of “Done”. An in­cre­ment is a body of in­spectable, done work that sup­ports em­piri­cism at the end of the Sprint. The in­cre­ment is a step to­ward a vi­sion or goal. The in­cre­ment must be in use­able con­di­tion re­gard­less of whether the Prod­uct Own­er de­cides to re­lease it.

To learn more about Scrum, Join one of our workshops.

Upcoming Scrum Trainings

There are no up­com­ing events.