Scrum is a frame­work for devel­op­ing, deliv­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 defin­i­tive method. Rather, it is a frame­work with­in which you can employ var­i­ous process­es and tech­niques. Scrum makes clear the rel­a­tive effi­ca­cy of your prod­uct man­age­ment and work tech­niques so that you can con­tin­u­ous­ly improve the prod­uct, the team, and the work­ing environment.The Scrum frame­work con­sists of Scrum Teams and their asso­ci­at­ed roles, events, arti­facts, and rules. Each com­po­nent with­in the frame­work serves a spe­cif­ic pur­pose and is essen­tial to Scrum’s suc­cess and usage.

Scrum Framework


How Scrum embraces empiricism

Scrum is found­ed on empir­i­cal process con­trol the­o­ry or empiri­cism. Empiri­cism asserts that knowl­edge comes from expe­ri­ence and mak­ing deci­sions based on what is known. Scrum employs an iter­a­tive, incre­men­tal approach to opti­mize pre­dictabil­i­ty and con­trol risk. Three pil­lars uphold every imple­men­ta­tion of empir­i­cal process con­trol: trans­paren­cy, inspec­tion, and adap­ta­tion.


Sig­nif­i­cant aspects of the process must be vis­i­ble to those respon­si­ble for the out­come. Trans­paren­cy requires those aspects be defined by a com­mon stan­dard so observers share a com­mon under­stand­ing of what is being seen.

For exam­ple:

  • A com­mon lan­guage refer­ring to the process must be shared by all par­tic­i­pants; and,
  • Those per­form­ing the work and those inspect­ing the result­ing incre­ment must share a com­mon def­i­n­i­tion of “Done”.


Scrum users must fre­quent­ly inspect Scrum arti­facts and progress toward a Sprint Goal to detect unde­sir­able vari­ances. Their inspec­tion should not be so fre­quent that inspec­tion gets in the way of the work. Inspec­tions are most ben­e­fi­cial when dili­gent­ly per­formed by skilled inspec­tors at the point of work.


If an inspec­tor deter­mines that one or more aspects of a process devi­ate out­side accept­able lim­its, and that the result­ing prod­uct will be unac­cept­able, the process or the mate­r­i­al being processed must be adjust­ed. An adjust­ment must be made as soon as pos­si­ble to min­i­mize fur­ther devi­a­tion.

Scrum pre­scribes four for­mal events for inspec­tion and adap­ta­tion, as described in the Scrum Events sec­tion of this doc­u­ment:

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

Scrum Values

When the val­ues of com­mit­ment, courage, focus, open­ness, and respect are embod­ied and lived by the Scrum Team, the Scrum pil­lars of trans­paren­cy, inspec­tion, and adap­ta­tion come to life and build trust for every­one. The Scrum Team mem­bers learn and explore those val­ues as they work with the Scrum events, roles, and arti­facts.

Suc­cess­ful use of Scrum depends on peo­ple becom­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 focus­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 respect each oth­er to be capa­ble, inde­pen­dent peo­ple.

The Scrum Team

The Scrum Team con­sists of a Prod­uct Own­er, the Devel­op­ment Team, and a Scrum Mas­ter. Scrum Teams are self-orga­niz­ing and cross-func­tion­al. Self-orga­niz­ing teams choose how best to accom­plish their work, rather than being direct­ed by oth­ers out­side the team. Cross-func­tion­al teams have all com­pe­ten­cies need­ed to accom­plish the work with­out depend­ing on oth­ers not part of the team. The team mod­el in Scrum is designed to opti­mize flex­i­bil­i­ty, cre­ativ­i­ty, and pro­duc­tiv­i­ty. The Scrum Team has proven itself to be increas­ing­ly effec­tive for all the ear­li­er stat­ed uses, and any com­plex work.

Scrum Teams deliv­er prod­ucts iter­a­tive­ly and incre­men­tal­ly, max­i­miz­ing oppor­tu­ni­ties for feed­back. Incre­men­tal deliv­er­ies of “Done” prod­uct ensure a poten­tial­ly use­ful ver­sion of work­ing prod­uct is always avail­able.

The Product Owner

The Prod­uct Own­er is respon­si­ble for max­i­miz­ing the val­ue of the prod­uct result­ing from work of the Devel­op­ment Team. How this is done may vary wide­ly across orga­ni­za­tions, Scrum Teams, and indi­vid­u­als.

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

  • Clear­ly express­ing Prod­uct Back­log items;
  • Order­ing the items in the Prod­uct Back­log to best achieve goals and mis­sions;
  • Opti­miz­ing the val­ue of the work the Devel­op­ment Team per­forms;
  • Ensur­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,
  • Ensur­ing the Devel­op­ment Team under­stands items in the Prod­uct Back­log to the lev­el need­ed.

The Prod­uct Own­er may do the above work, or have the Devel­op­ment Team do it. How­ev­er, the Prod­uct Own­er remains account­able.

The Prod­uct Own­er is one per­son, not a com­mit­tee. The Prod­uct Own­er may rep­re­sent the desires 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 address the Prod­uct Own­er.

For the Prod­uct Own­er to suc­ceed, the entire orga­ni­za­tion must respect his or her deci­sions. The Prod­uct Owner’s deci­sions are vis­i­ble in the con­tent and order­ing of the Prod­uct Back­log. No one can force the Devel­op­ment Team to work from a dif­fer­ent set of require­ments.

The Development Team

The Devel­op­ment Team con­sists of pro­fes­sion­als who do the work of deliv­er­ing a poten­tial­ly releasable Incre­ment of “Done” prod­uct at the end of each Sprint. A “Done” incre­ment is required at the Sprint Review. Only mem­bers of the Devel­op­ment Team cre­ate the Incre­ment.

Devel­op­ment Teams are struc­tured and empow­ered by the orga­ni­za­tion to orga­nize and man­age their own work. The result­ing syn­er­gy opti­mizes the Devel­op­ment Team’s over­all effi­cien­cy and effec­tive­ness.

Devel­op­ment Teams have the fol­low­ing char­ac­ter­is­tics:

  • They are self-orga­niz­ing. No one (not even the Scrum Mas­ter) tells the Devel­op­ment Team how to turn Prod­uct Back­log into Incre­ments of poten­tial­ly releasable func­tion­al­i­ty;
  • Devel­op­ment Teams are cross-func­tion­al, with all the skills as a team nec­es­sary to cre­ate a prod­uct Incre­ment;
  • Scrum rec­og­nizes no titles for Devel­op­ment Team mem­bers, regard­less of the work being per­formed by the per­son;
  • Scrum rec­og­nizes no sub-teams in the Devel­op­ment Team, regard­less of domains that need to be addressed like test­ing, archi­tec­ture, oper­a­tions, or busi­ness analy­sis; and,
  • Indi­vid­ual Devel­op­ment Team mem­bers may have spe­cial­ized skills and areas of focus, but account­abil­i­ty belongs to the Devel­op­ment Team as a whole.


The Scrum Master

The Scrum Mas­ter is respon­si­ble for pro­mot­ing and sup­port­ing Scrum as defined in the Scrum Guide. Scrum Mas­ters do this by help­ing every­one under­stand Scrum the­o­ry, prac­tices, rules, and val­ues.

The Scrum Mas­ter is a ser­vant-leader for the Scrum Team. The Scrum Mas­ter helps those out­side the Scrum Team under­stand which of their inter­ac­tions with the Scrum Team are help­ful and which aren’t. The Scrum Mas­ter helps every­one change these inter­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, includ­ing:

  • Ensur­ing that goal, scope, and prod­uct domain are under­stood by every­one on the Scrum Team as well as pos­si­ble;
  • Find­ing tech­niques for effec­tive Prod­uct Back­log man­age­ment;
  • Help­ing the Scrum Team under­stand the need for clear and con­cise Prod­uct Back­log items;
  • Under­stand­ing prod­uct plan­ning in an empir­i­cal envi­ron­ment;
  • Ensur­ing the Prod­uct Own­er knows how to arrange the Prod­uct Back­log to max­i­mize val­ue;
  • Under­stand­ing and prac­tic­ing agili­ty; and,
  • Facil­i­tat­ing Scrum events as request­ed or need­ed.

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 defined in Scrum. All events are time-boxed events, such that every event has a max­i­mum dura­tion. Once a Sprint begins, its dura­tion is fixed and can­not be short­ened or length­ened. The remain­ing events may end when­ev­er the pur­pose of the event is achieved, ensur­ing an appro­pri­ate amount of time is spent with­out allow­ing waste in the process.

Oth­er than the Sprint itself, which is a con­tain­er for all oth­er events, each event in Scrum is a for­mal oppor­tu­ni­ty to inspect and adapt some­thing. These events are specif­i­cal­ly designed to enable crit­i­cal trans­paren­cy and inspec­tion. Fail­ure to include any of these events results in reduced trans­paren­cy and is a lost oppor­tu­ni­ty to inspect 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 poten­tial­ly releasable prod­uct Incre­ment is cre­at­ed. Sprints have con­sis­tent dura­tions through­out a devel­op­ment effort. A new Sprint starts imme­di­ate­ly after 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 devel­op­ment work, the Sprint Review, and the Sprint Ret­ro­spec­tive.

Dur­ing the Sprint:

  • No changes are made that would endan­ger the Sprint Goal;
  • Qual­i­ty goals do not decrease; and,
  • Scope may be clar­i­fied and re-nego­ti­at­ed between the Prod­uct Own­er and Devel­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 accom­plish some­thing. Each Sprint has a goal of what is to be built, a design and flex­i­ble plan that will guide build­ing it, the work, and the resul­tant prod­uct incre­ment.

Sprints are lim­it­ed to one cal­en­dar month. When a Sprint’s hori­zon is too long the def­i­n­i­tion of what is being built may change, com­plex­i­ty may rise, and risk may increase. Sprints enable pre­dictabil­i­ty by ensur­ing inspec­tion and adap­ta­tion of progress toward 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 entire 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 ensures that the event takes place and that atten­dants under­stand its pur­pose. The Scrum Mas­ter teach­es the Scrum Team to keep it with­in the time-box.

Sprint Plan­ning answers the fol­low­ing:

  • What can be deliv­ered in the Incre­ment result­ing from the upcom­ing Sprint?
  • How will the work need­ed to deliv­er the Incre­ment be achieved?

Topic One: What can be done this Sprint?

The Devel­op­ment Team works to fore­cast the func­tion­al­i­ty that will be devel­oped dur­ing the Sprint. The Prod­uct Own­er dis­cuss­es the objec­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 entire Scrum Team col­lab­o­rates on under­stand­ing the work of the Sprint.

The input to this meet­ing is the Prod­uct Back­log, the lat­est prod­uct Incre­ment, pro­ject­ed capac­i­ty of the Devel­op­ment Team dur­ing the Sprint, and past per­for­mance of the Devel­op­ment Team. The num­ber of items select­ed from the Prod­uct Back­log for the Sprint is sole­ly up to the Devel­op­ment Team. Only the Devel­op­ment Team can assess what it can accom­plish over the upcom­ing Sprint.

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

Topic Two: how will the chosen work get done?

Hav­ing set the Sprint Goal and select­ed the Prod­uct Back­log items for the Sprint, the Devel­op­ment Team decides how it will build this func­tion­al­i­ty into a “Done” prod­uct Incre­ment dur­ing the Sprint. The Prod­uct Back­log items select­ed for this Sprint plus the plan for deliv­er­ing them is called the Sprint Back­log.

The Devel­op­ment Team usu­al­ly starts by design­ing the sys­tem and the work need­ed to con­vert the Prod­uct Back­log into a work­ing prod­uct Incre­ment. Work may be of vary­ing size, or esti­mat­ed effort. How­ev­er, enough work is planned dur­ing Sprint Plan­ning for the Devel­op­ment Team to fore­cast what it believes it can do in the upcom­ing Sprint. Work planned for the first days of the Sprint by the Devel­op­ment Team is decom­posed by the end of this meet­ing, often to units of one day or less. The Devel­op­ment Team self-orga­nizes to under­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 select­ed Prod­uct Back­log items and make trade-offs. If the Devel­op­ment Team deter­mines it has too much or too lit­tle work, it may rene­go­ti­ate the select­ed Prod­uct Back­log items with the Prod­uct Own­er. The Devel­op­ment Team may also invite oth­er peo­ple to attend to pro­vide tech­ni­cal or domain advice.

By the end of the Sprint Plan­ning, the Devel­op­ment Team should be able to explain to the Prod­uct Own­er and Scrum Mas­ter how it intends to work as a self-orga­niz­ing team to accom­plish the Sprint Goal and cre­ate the antic­i­pat­ed Incre­ment.

Sprint Goal

The Sprint Goal is an objec­tive set for the Sprint that can be met through the imple­men­ta­tion of Prod­uct Back­log. It pro­vides guid­ance to the Devel­op­ment Team on why it is build­ing the Incre­ment. It is cre­at­ed dur­ing the Sprint Plan­ning meet­ing. The Sprint Goal gives the Devel­op­ment Team some flex­i­bil­i­ty regard­ing the func­tion­al­i­ty imple­ment­ed with­in the Sprint. The select­ed Prod­uct Back­log items deliv­er one coher­ent func­tion, which can be the Sprint Goal. The Sprint Goal can be any oth­er coher­ence that caus­es the Devel­op­ment Team to work togeth­er rather than on sep­a­rate ini­tia­tives.

As the Devel­op­ment Team works, it keeps the Sprint Goal in mind. In order to sat­is­fy the Sprint Goal, it imple­ments func­tion­al­i­ty and tech­nol­o­gy. If the work turns out to be dif­fer­ent than the Devel­op­ment Team expect­ed, they col­lab­o­rate with the Prod­uct Own­er to nego­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 Devel­op­ment Team. The Dai­ly Scrum is held every day of the Sprint. At it, the Devel­op­ment Team plans work for the next 24 hours. This opti­mizes team col­lab­o­ra­tion and per­for­mance by inspect­ing the work since the last Dai­ly Scrum and fore­cast­ing upcom­ing Sprint work. The Dai­ly Scrum is held at the same time and place each day to reduce com­plex­i­ty.

The Devel­op­ment Team uses the Dai­ly Scrum to inspect progress toward the Sprint Goal and to inspect how progress is trend­ing toward com­plet­ing the work in the Sprint Back­log. The Dai­ly Scrum opti­mizes the prob­a­bil­i­ty that the Devel­op­ment Team will meet the Sprint Goal. Every day, the Devel­op­ment Team should under­stand how it intends to work togeth­er as a self-orga­niz­ing team to accom­plish the Sprint Goal and cre­ate the antic­i­pat­ed Incre­ment by the end of the Sprint.

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

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

The Devel­op­ment Team or team mem­bers often meet imme­di­ate­ly after the Dai­ly Scrum for detailed dis­cus­sions, or to adapt, or replan, the rest of the Sprint’s work.

The Scrum Mas­ter ensures that the Devel­op­ment Team has the meet­ing, but the Devel­op­ment Team is respon­si­ble for con­duct­ing the Dai­ly Scrum. The Scrum Mas­ter teach­es the Devel­op­ment Team to keep the Dai­ly Scrum with­in the 15-minute time-box.

The Dai­ly Scrum is an inter­nal meet­ing for the Devel­op­ment Team. If oth­ers are present, the Scrum Mas­ter ensures that they do not dis­rupt the meet­ing.

Dai­ly Scrums improve com­mu­ni­ca­tions, elim­i­nate oth­er meet­ings, iden­ti­fy imped­i­ments to devel­op­ment for removal, high­light and pro­mote quick deci­sion-mak­ing, and improve the Devel­op­ment Team’s lev­el of knowl­edge. This is a key inspect and adapt meet­ing.

Sprint Review

A Sprint Review is held at the end of the Sprint to inspect the Incre­ment and adapt the Prod­uct Back­log if need­ed. Dur­ing the Sprint Review, 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, atten­dees col­lab­o­rate on the next things that could be done to opti­mize val­ue. This is an infor­mal meet­ing, not a sta­tus meet­ing, and the pre­sen­ta­tion of the Incre­ment is intend­ed to elic­it feed­back and fos­ter col­lab­o­ra­tion.

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 ensures that the event takes place and that atten­dees under­stand its pur­pose. The Scrum Mas­ter teach­es every­one involved to keep it with­in the time-box.

The Sprint Review includes the fol­low­ing ele­ments:

  • Atten­dees include the Scrum Team and key stake­hold­ers invit­ed by the Prod­uct Own­er;
  • The Prod­uct Own­er explains what Prod­uct Back­log items have been “Done” and what has not been “Done”;
  • The Devel­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 Devel­op­ment Team demon­strates the work that it has “Done” and answers ques­tions about the Incre­ment;
  • 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 deliv­ery dates based on progress to date (if need­ed);
  • The entire group col­lab­o­rates on what to do next, so that the Sprint Review pro­vides valu­able input to sub­se­quent Sprint Plan­ning;
  • Review of how the mar­ket­place or poten­tial use of the prod­uct might have changed what is the most valu­able thing to do next; and,
  • Review of the time­line, bud­get, poten­tial capa­bil­i­ties, and mar­ket­place for the next antic­i­pat­ed releas­es of func­tion­al­i­ty or capa­bil­i­ty of the prod­uct.

The result of the Sprint Review is a revised Prod­uct Back­log that defines the prob­a­ble Prod­uct Back­log items for the next Sprint. The Prod­uct Back­log may also be adjust­ed over­all to meet new oppor­tu­ni­ties.

Sprint Retrospective

The Sprint Ret­ro­spec­tive is an oppor­tu­ni­ty for the Scrum Team to inspect itself and cre­ate a plan for improve­ments to be enact­ed dur­ing the next Sprint.

The Sprint Ret­ro­spec­tive occurs after the Sprint Review 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 ensures that the event takes place and that atten­dants under­stand its pur­pose.

The Scrum Mas­ter ensures 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 account­abil­i­ty over the Scrum process.

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

  • Inspect how the last Sprint went with regards to peo­ple, rela­tion­ships, process, and tools;
  • Iden­ti­fy and order the major items that went well and poten­tial improve­ments; and,
  • Cre­ate a plan for imple­ment­ing improve­ments to the way the Scrum Team does its work.

The Scrum Mas­ter encour­ages the Scrum Team to improve, with­in the Scrum process frame­work, its devel­op­ment process and prac­tices to make it more effec­tive and enjoy­able for the next Sprint. Dur­ing each Sprint Ret­ro­spec­tive, the Scrum Team plans ways to increase prod­uct qual­i­ty by improv­ing work process­es or adapt­ing the def­i­n­i­tion of “Done”, if appro­pri­ate and not in con­flict with prod­uct or orga­ni­za­tion­al stan­dards.

By the end of the Sprint Ret­ro­spec­tive, the Scrum Team should have iden­ti­fied improve­ments that it will imple­ment in the next Sprint. Imple­ment­ing these improve­ments in the next Sprint is the adap­ta­tion to the inspec­tion of the Scrum Team itself. Although improve­ments may be imple­ment­ed at any time, the Sprint Ret­ro­spec­tive pro­vides a for­mal oppor­tu­ni­ty to focus on inspec­tion and adap­ta­tion.

Scrum Artifacts

Scrum’s arti­facts rep­re­sent work or val­ue to pro­vide trans­paren­cy and oppor­tu­ni­ties for inspec­tion and adap­ta­tion. Arti­facts defined by Scrum are specif­i­cal­ly designed to max­i­mize trans­paren­cy of key infor­ma­tion so that every­body has the same under­stand­ing of the arti­fact.

Product Backlog

The Prod­uct Back­log is an ordered list of every­thing that is known to be need­ed in the prod­uct. It is the sin­gle source of require­ments for any changes to be made to the prod­uct. The Prod­uct Own­er is respon­si­ble for the Prod­uct Back­log, includ­ing its con­tent, avail­abil­i­ty, and order­ing.

A Prod­uct Back­log is nev­er com­plete. The ear­li­est devel­op­ment of it lays out the ini­tial­ly known and best-under­stood require­ments. The Prod­uct Back­log evolves as the prod­uct and the envi­ron­ment in which it will be used evolves. The Prod­uct Back­log is dynam­ic; it con­stant­ly changes to iden­ti­fy what the prod­uct needs to be appro­pri­ate, com­pet­i­tive, and use­ful. If a prod­uct exists, its Prod­uct Back­log also exists.

The Prod­uct Back­log lists all fea­tures, func­tions, require­ments, enhance­ments, and fix­es that con­sti­tute the changes to be made to the prod­uct in future releas­es. Prod­uct Back­log items have the attrib­ut­es of a descrip­tion, order, esti­mate, and val­ue. Prod­uct Back­log items often include test descrip­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 becomes a larg­er and more exhaus­tive list. Require­ments nev­er stop chang­ing, so a Prod­uct Back­log is a liv­ing arti­fact. Changes in busi­ness require­ments, mar­ket con­di­tions, or tech­nol­o­gy may cause changes in the Prod­uct Back­log.

Mul­ti­ple Scrum Teams often work togeth­er on the same prod­uct. One Prod­uct Back­log is used to describe the upcom­ing work on the prod­uct. A Prod­uct Back­log attribute that groups items may then be employed.

Prod­uct Back­log refine­ment is the act of adding detail, esti­mates, and order to items in the Prod­uct Back­log. This is an ongo­ing process in which the Prod­uct Own­er and the Devel­op­ment Team col­lab­o­rate on the details of Prod­uct Back­log items. Dur­ing Prod­uct Back­log refine­ment, items are reviewed and revised. The Scrum Team decides how and when refine­ment is done. Refine­ment usu­al­ly con­sumes no more than 10% of the capac­i­ty of the Devel­op­ment Team. How­ev­er, Prod­uct Back­log items can be updat­ed at any time by the Prod­uct Own­er or at the Prod­uct Owner’s dis­cre­tion.

High­er ordered Prod­uct Back­log items are usu­al­ly clear­er and more detailed than low­er ordered ones. More pre­cise esti­mates are made based on the greater clar­i­ty and increased detail; the low­er the order, the less detail. Prod­uct Back­log items that will occu­py the Devel­op­ment Team for the upcom­ing Sprint are refined 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 Devel­op­ment Team with­in one Sprint are deemed “Ready” for selec­tion in a Sprint Plan­ning. Prod­uct Back­log items usu­al­ly acquire this degree of trans­paren­cy through the above described refin­ing activ­i­ties.

The Devel­op­ment Team is respon­si­ble for all esti­mates. The Prod­uct Own­er may influ­ence the Devel­op­ment Team by help­ing it under­stand and select trade-offs, but the peo­ple who will per­form the work make the final esti­mate.

Monitoring Progress Toward Goals

At any point in time, the total work remain­ing to reach a goal can be summed. The Prod­uct Own­er tracks this total work remain­ing at least every Sprint Review. The Prod­uct Own­er com­pares this amount with work remain­ing at pre­vi­ous Sprint Reviews to assess progress toward com­plet­ing pro­ject­ed work by the desired time for the goal. This infor­ma­tion is made trans­par­ent to all stake­hold­ers.

Var­i­ous pro­jec­tive prac­tices upon trend­ing have been used to fore­cast progress, like burn-downs, burn-ups, or cumu­la­tive flows. These have proven use­ful. How­ev­er, these do not replace the impor­tance of empiri­cism. In com­plex envi­ron­ments, what will hap­pen is unknown. Only what has already hap­pened may be used for for­ward-look­ing deci­sion-mak­ing.

Sprint Backlog

The Sprint Back­log is the set of Prod­uct Back­log items select­ed for the Sprint, plus a plan for deliv­er­ing the prod­uct Incre­ment and real­iz­ing the Sprint Goal. The Sprint Back­log is a fore­cast by the Devel­op­ment Team about what func­tion­al­i­ty will be in the next Incre­ment and the work need­ed to deliv­er that func­tion­al­i­ty into a “Done” Incre­ment.

The Sprint Back­log makes vis­i­ble all the work that the Devel­op­ment Team iden­ti­fies as nec­es­sary to meet the Sprint Goal. To ensure con­tin­u­ous improve­ment, it includes at least one high pri­or­i­ty process improve­ment iden­ti­fied in the pre­vi­ous Ret­ro­spec­tive meet­ing.

The Sprint Back­log is a plan with enough detail that changes in progress can be under­stood in the Dai­ly Scrum. The Devel­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 occurs as the Devel­op­ment Team works through the plan and learns more about the work need­ed to achieve the Sprint Goal.

As new work is required, the Devel­op­ment Team adds it to the Sprint Back­log. As work is per­formed or com­plet­ed, the esti­mat­ed remain­ing work is updat­ed. When ele­ments of the plan are deemed unnec­es­sary, they are removed. Only the Devel­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 Devel­op­ment Team plans to accom­plish dur­ing the Sprint, and it belongs sole­ly to the Devel­op­ment Team.

Monitoring Sprint Progress

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


The Incre­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 incre­ments of all pre­vi­ous Sprints. At the end of a Sprint, the new Incre­ment must be “Done,” which means it must be in use­able con­di­tion and meet the Scrum Team’s def­i­n­i­tion of “Done”. An incre­ment is a body of inspectable, done work that sup­ports empiri­cism at the end of the Sprint. The incre­ment is a step toward a vision or goal. The incre­ment must be in use­able con­di­tion regard­less of whether the Prod­uct Own­er decides to release it.

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

Upcoming Scrum Trainings

Es gibt derzeit keine bevorste­hen­den Ver­anstal­tun­gen.