Misplaced Pages

Timeboxing: Difference between revisions

Article snapshot taken from Wikipedia with creative commons attribution-sharealike license. Give it a read and then ask your questions in the chat. We can research this topic together.
Browse history interactively← Previous editContent deleted Content addedVisualWikitext
Revision as of 10:53, 19 September 2016 editEntranced98 (talk | contribs)Extended confirmed users, Pending changes reviewers, Rollbackers173,356 editsm Reverted edits by 62.171.196.106 (talk) to last version by 107.77.208.194← Previous edit Latest revision as of 08:12, 2 April 2024 edit undoUla993 (talk | contribs)Extended confirmed users585 edits →See also: add dotTag: Visual edit 
(45 intermediate revisions by 30 users not shown)
Line 1: Line 1:
{{short description|Time management method}}
{{software development process}} {{software development process}}


In ], '''timeboxing''' allocates a maximum unit of time to an activity, called a '''timebox''', within which a planned activity takes place. It is used by agile principles-based ] approaches and for personal time management.
In ], '''timeboxing''' allocates a fixed time period, called a '''time box''', to each planned activity. Several ] approaches use timeboxing. It is also used for individual use to address personal tasks in a smaller time frame. It often involves having deliverables and deadlines, which will improve the productivity of the user.{{Citation needed|date=June 2016}} {{Rquote|right|Timebox—don't scopebox.''| Mary Poppendieck | ''Leading Lean Software Development''<ref>{{cite book | last = Poppendieck | first = Mary | title = Leading Lean Software Development: Results Are Not the Point | publisher = Addison-Wesley | location = Upper Saddle River, NJ | page = 139 | year = 2010 | isbn = 978-0-321-62070-5 }}</ref>}}


== In project management == == In project management ==


Timeboxing is used as a ] technique. The schedule is divided into a number of separate time periods (timeboxes), with each part having its own deliverables, deadline and budget.{{Citation needed|date=November 2011}} Timeboxing is used as a ] technique. The schedule is divided into a number of separate time periods (timeboxes), with each part having its own deliverables, ] and budget.{{Citation needed|date=November 2011}} Sometimes referred to as ''schedule as independent variable'' (SAIV).<ref>{{Cite book|url=https://books.google.com/books?id=MWhXwkHsS0gC&q=%22Schedule+as%22&pg=PA212|title=Balancing Agility and Discipline: A Guide for the Perplexed|last1=Boehm|first1=Barry W.|last2=Boehm|first2=Barry|last3=Turner|first3=Richard|date=2004|publisher=Addison-Wesley Professional|isbn=9780321186126|language=en}}</ref> "Timeboxing works best in multistage projects or tasks that take little time and you can fit them in the same time slot. It is also worth implementing in case of duties that have foreseeable time-frames of completion."<ref>{{Cite web|date=2022-01-17|title=Timeboxing – why you should use it?|url=https://firmbee.com/timeboxing-why-you-should-use-it/|access-date=2022-01-25|website=Firmbee|language=en}}</ref>


=== As an alternative to fixing scope === === As an alternative to fixing scope ===


In ], the ] are time (sometimes ]), cost (sometimes ]), and ] (sometimes performance).<ref>, article by Rod Hutchings on (22 Oct 2008)</ref><ref name="Chat">{{Cite news| first=Carl | last=Chatfield | title=A short course in project management | url=http://office.microsoft.com/en-us/project/HA102354821033.aspx| publisher=Microsoft}}</ref><ref>{{cite book | last = Dobson | first = Michael | title = The triple constraints in project management | publisher = Management Concepts | location = Vienna, Va | year = 2004 | isbn = 1-56726-152-3 }}</ref><ref name=Kanabar/><ref name=Leffingwell/> ] is often added,<ref>{{cite book |last= Snedaker |first= Susan |author2=Nels Hoenig |title= How to Cheat at IT Project Management |publisher= Syngress |year= 2005 |isbn= 1-59749-037-7 }}</ref><ref>{{cite book | last = Beck | first = Kent | title = Extreme programming eXplained : embrace change | publisher = Addison-Wesley | location = Reading, MA | year = 2000 | isbn = 0-201-61641-6 | pages=15–19 }}</ref> sometimes replacing cost.<ref name=Dangelo>{{cite book | last = Dangelo | first = Mark | title = Innovative relevance : realigning the organization for profit : it is not a battle for the "shore lines" - it's a struggle for purpose | publisher = iUniverse | location = New York | year = 2005 | isbn = 978-0-595-67081-9 | page=53 | url=http://books.google.co.uk/books?id=LQx3lab0KnIC}}</ref> Changing one constraint will probably impact the rest.<ref name=Kanabar>{{cite book | last = Kanabar | first = Vijay | title = MBA Fundamentals : Project Management | publisher = Kaplan Pub | location = New York | year = 2008 | page = 51 | isbn = 978-1-4277-9744-5 }}</ref> In ], there are generally considered to be ]: time (sometimes ]), cost (sometimes ]), and ].<ref> {{webarchive|url=https://archive.today/20060820021929/http://www.projectmanagement.net.au/triple_constraints |date=2006-08-20 }}, article by Rod Hutchings on {{webarchive|url=https://web.archive.org/web/20090216052557/http://projectmanagement.net.au/ |date=2009-02-16 }} (22 Oct 2008)</ref><ref name="Chat">{{Cite news| first=Carl | last=Chatfield | title=A short course in project management | url=http://office.microsoft.com/en-us/project/HA102354821033.aspx| publisher=Microsoft}}</ref><ref>{{cite book | last = Dobson | first = Michael | title = The triple constraints in project management | publisher = Management Concepts | location = Vienna, Va | year = 2004 | isbn = 1-56726-152-3 }}</ref><ref name=Kanabar/><ref name=Leffingwell/> (] is often added as a fourth constraint---represented as the middle of a triangle.<ref>{{cite book |last= Snedaker |first= Susan |author2=Nels Hoenig |title= How to Cheat at IT Project Management |publisher= Syngress |year= 2005 |isbn= 1-59749-037-7 }}</ref><ref>{{cite book | last = Beck | first = Kent | title = Extreme programming eXplained: embrace change | publisher = Addison-Wesley | location = Reading, MA | year = 2000 | isbn = 0-201-61641-6 | pages = –19 | url = https://archive.org/details/extremeprogrammi00beck | url-access = limited }}</ref><ref name=Dangelo>{{cite book | last = Dangelo | first = Mark | title = Innovative relevance: realigning the organization for profit: it is not a battle for the "shore lines" - it's a struggle for purpose | publisher = iUniverse | location = New York | year = 2005 | isbn = 978-0-595-67081-9 | page=53 | url=https://books.google.com/books?id=LQx3lab0KnIC}}</ref>) The assumption is that a change in one constraint will affect the others.<ref name=Kanabar>{{cite book | last = Kanabar | first = Vijay | title = MBA Fundamentals: Project Management | publisher = Kaplan Pub | location = New York | year = 2008 | page = 51 | isbn = 978-1-4277-9744-5 }}</ref>


Without timeboxing, projects usually work to a fixed scope,<ref>{{cite book |last= Godin |first= Seth |title= Getting Real: The smarter, faster, easier way to build a successful web application |publisher= 37signals }}</ref> such that when it is clear that some deliverables cannot be completed, either the deadline slips (to allow more time) or more people are involved (to do more in the same time). Usually both happen, delivery is late, costs go up, and often quality suffers (as per the ] principle). Without timeboxing, projects usually work to a fixed scope,<ref>{{cite book |last= Godin |first= Seth |title= Getting Real: The smarter, faster, easier way to build a successful web application |publisher= 37signals }}</ref> in which case when it becomes clear that some deliverables cannot be completed within the planned timescales, either the deadline has to be extended (to allow more time to complete the fixed scope) or more people are involved (to complete the fixed scope in the same time). Often both happen, resulting in delayed delivery, increased costs, and often reduced quality (as per ] principle).


With timeboxing, the deadline is fixed, but the scope may be reduced. This focuses work on the most important deliverables. For this reason, timeboxing depends on the prioritisation (with the ] for example) of deliverables, to ensure that it is the ] who determine the important deliverables rather than ]s.{{Citation needed|date=June 2009}} With timeboxing, the deadline is fixed, meaning that the scope would have to be reduced. As this means organizations have to focus on completing the most important deliverables first, timeboxing often goes hand-in-hand with a scheme for prioritizing of deliverables (such as with the ]).<ref name=":0">{{Cite book|title=DSDM, dynamic systems development method: the method in practice|last=Jennifer.|first=Stapleton|date=1997|publisher=Addison-Wesley|isbn=0201178893|location=Harlow, England|oclc=36755892}}</ref>


=== To manage risk === === To manage risk ===
Line 31: Line 32:
Timeboxing has been adopted by some notable ]: Timeboxing has been adopted by some notable ]:


* ] (DSDM) {{Citation needed|date=November 2011}} * ] (DSDM).<ref name=":0" />
* In ], ] with ] provides short term time management. When developing a large and complex system, when long term ] is required timeboxing is ] above.<ref>{{cite book | last = Poppendieck | first = Mary | title = Leading Lean Software Development : Results are not the Point | publisher = Addison-Wesley | location = Upper Saddle River, NJ | pages = 137–140 | year = 2010 | isbn = 978-0-321-62070-5 }}</ref> * In ], ] with ] provides short term time management. When developing a large and complex system, where long term ] is required, timeboxing is ] above.<ref>{{cite book | last = Poppendieck | first = Mary | title = Leading Lean Software Development: Results are not the Point | publisher = Addison-Wesley | location = Upper Saddle River, NJ | pages = 137–140 | year = 2010 | isbn = 978-0-321-62070-5 }}</ref>
* ] (RAD) ] features ] and ]. According to ], timeboxing is a "Best Practice" for RAD and a typical timebox length should be 60–120 days.<ref name=McConnell>{{cite book | last = McConnell | first = Steve | title = Rapid Development : taming wild software schedules | publisher = Microsoft Press | location = Redmond, Wash | year = 1996 | isbn = 1-55615-900-5 | pages=575–583}}</ref> * ] (RAD) ] features ] and ]. According to ], timeboxing is a "Best Practice" for RAD and a typical timebox length should be 60–120 days.<ref name=McConnell>{{cite book | last = McConnell | first = Steve | title = Rapid Development: taming wild software schedules | publisher = Microsoft Press | location = Redmond, Wash | year = 1996 | isbn = 1-55615-900-5 | pages = –583 | url = https://archive.org/details/rapiddevelopment00mcco | url-access = limited }}</ref>
* ] was influenced by ideas of timeboxing and ].<ref>{{cite book | last = Coplien | first = James | title = Lean Architecture for Agile Software Development | publisher = Wiley | location = Chichester Hoboken, N.J | year = 2010 | url = http://books.google.co.uk/books?id=lpvY36MPMUwC | page = 25 | isbn = 978-0-470-68420-7 }}</ref> Regular timeboxed units known as ] form the basic unit of development.<ref>{{cite book | last = Cohn | first = Mike | title = Succeeding with Agile : Software Development using Scrum | publisher = Addison-Wesley | location = Upper Saddle River, NJ | year = 2010 | pages = 257–284 | isbn = 978-0-321-57936-2 }}</ref> A typical length for a sprint is 30 days.<ref name=Schwaber/><ref>{{cite book | last = Leffingwell | first = Dean | title = Agile Software Requirements : Lean requirements practices for teams, programs, and the enterprise | publisher = Addison-Wesley | location = Upper Saddle River, NJ | year = 2011 | isbn = 978-0-321-63584-6 | pages = 15 | url = http://books.google.co.uk/books?id=pTExbNmZwZUC }}</ref> Sprint planning, sprint retrospective and sprint review meetings are timeboxed.<ref name=Schwaber>{{cite book | last = Schwaber | first = Ken | title = Agile Project Management with Scrum | publisher = O'Reilly Media, Inc | location = New York | year = 2009 | url = http://books.google.co.uk/books?id=RpYX01XVMksC | isbn = 978-0-7356-3790-0 }}</ref> * ] was influenced by ideas of timeboxing and ].<ref>{{cite book | last = Coplien | first = James | title = Lean Architecture for Agile Software Development | publisher = Wiley | location = Chichester Hoboken, N.J | year = 2010 | url = https://books.google.com/books?id=lpvY36MPMUwC | page = 25 | isbn = 978-0-470-68420-7 }}</ref> Regular timeboxed units known as ] form the basic unit of development.<ref>{{cite book | last = Cohn | first = Mike | title = Succeeding with Agile: Software Development using Scrum | url = https://archive.org/details/succeedingwithag00cohn_599 | url-access = limited | publisher = Addison-Wesley | location = Upper Saddle River, NJ | year = 2010 | pages = –284 | isbn = 978-0-321-57936-2 }}</ref> A typical length for a sprint is less than 30 days.<ref name=Schwaber/><ref>{{cite book | last = Leffingwell | first = Dean | title = Agile Software Requirements: Lean requirements practices for teams, programs, and the enterprise | publisher = Addison-Wesley | location = Upper Saddle River, NJ | year = 2011 | isbn = 978-0-321-63584-6 | pages = 15 | url = https://books.google.com/books?id=pTExbNmZwZUC }}</ref> Sprint planning, sprint retrospective and sprint review meetings are timeboxed.<ref name=Schwaber>{{cite book | last = Schwaber | first = Ken | title = Agile Project Management with Scrum | publisher = O'Reilly Media, Inc | location = New York | year = 2009 | url = https://books.google.com/books?id=RpYX01XVMksC | isbn = 978-0-7356-3790-0 }}</ref>
* In ] methodologies, development planning is timeboxed into iterations typically 1, 2 or 3 weeks in length. The business ] pending ] before each iteration.<ref>{{cite book | last = Beck | first = Kent | title = Extreme programming eXplained : embrace change | publisher = Addison-Wesley | location = Reading, MA | year = 2000 | isbn = 0-201-61641-6 | pages=85–96 }}</ref> * In ] methodologies, development planning is timeboxed into iterations typically 1, 2 or 3 weeks in length. The business ] pending ] before each iteration.<ref>{{cite book | last = Beck | first = Kent | title = Extreme programming eXplained: embrace change | publisher = Addison-Wesley | location = Reading, MA | year = 2000 | isbn = 0-201-61641-6 | pages = –96 | url = https://archive.org/details/extremeprogrammi00beck | url-access = limited }}</ref>


] advocates moving from ''plan driven'' to ''value driven'' development. Quality and time are fixed but flexibility allowed in scope. Delivering the most important features first leads to an earlier ] than the ].<ref name=Leffingwell>{{cite book | last = Leffingwell | first = Dean | title = Agile Software Requirements : Lean requirements practices for teams, programs, and the enterprise | publisher = Addison-Wesley | location = Upper Saddle River, NJ | year = 2011 | isbn = 978-0-321-63584-6 | pages = 17–19 | url = http://books.google.co.uk/books?id=pTExbNmZwZUC }}</ref> ] advocates moving from ''plan driven'' to ''value driven'' development. Quality and time are fixed but flexibility allowed in scope. Delivering the most important features first leads to an earlier ] than the ].<ref name=Leffingwell>{{cite book | last = Leffingwell | first = Dean | title = Agile Software Requirements: Lean requirements practices for teams, programs, and the enterprise | publisher = Addison-Wesley | location = Upper Saddle River, NJ | year = 2011 | isbn = 978-0-321-63584-6 | pages = 17–19 | url = https://books.google.com/books?id=pTExbNmZwZUC }}</ref>


A lack of detailed specifications typically is the result of a lack of time, or the lack of knowledge of the desired end result (solution). In many types of projects, and especially in software engineering, analyzing and defining ''all'' requirements and specifications before the start of the realization phase is impossible. Timeboxing can be a favorable type of contracting for projects in which the deadline is ''the'' most critical aspect and when not all requirements are completely specified up front.{{Citation needed|date=June 2009}} A lack of detailed specifications typically is the result of a lack of time, or the lack of knowledge of the desired end result (solution). In many types of projects, and especially in software engineering, analyzing and defining ''all'' requirements and specifications before the start of the realization phase is impossible. Timeboxing can be a favorable type of contracting for projects in which the deadline is ''the'' most critical aspect and when not all requirements are completely specified up front. This also allows for new feedback or insights discovered during the project to be reflected in the end result.<ref name=":0" />

This is also a better structure for allowing for new insights that are developed during the project to be reflected in the end result.{{Citation needed|date=June 2009}}


== In personal time management == == In personal time management ==
{{Main|Timeblocking}}
Timeboxing can be used for personal tasks, in which case it uses a reduced scale of time (e.g., thirty minutes) and of deliverables (e.g., a household chore instead of project deliverable), and is often called ].


Individuals can use timeboxing for personal tasks, as well. This technique utilizes a reduced scale of time (e.g., thirty minutes instead of a week) and deliverables (e.g., chores instead of a component of a business project). Personal timeboxing is said to help curb perfectionist tendencies (by setting a firm time and not overcommitting to a task).<ref>{{cite web |url=http://www.whyamilazy.com/40-super-effective-ways-to-stop-procrastinating/ |title=40 Ways To Stop Procrastinating |last1=Frankton |first1=James |date=4 April 2014 |website=Why Am I Lazy? |accessdate=22 September 2014}}</ref> It is also suggested that personal time boxing can create an increased pressure for an individual which will lead to better creativity and focus towards a task. <ref>{{cite book | last = Pash | first = Adam | title = Lifehacker the guide to working smarter, faster, and better | publisher = Wiley | location = Indianapolis, Ind | year = 2011 | isbn = 978-1-118-13345-3 | url = http://books.google.co.uk/books?id=d-FYJceblAMC | at=Hack 29}}</ref> Personal timeboxing is also said to act as a ] to help curb perfectionist tendencies (by setting a firm time and not overcommitting to a task) which can also enhance creativity and focus (by creating a sense of urgency or increased pressure).<ref>{{cite book | last = Pash | first = Adam | title = Lifehacker the guide to working smarter, faster, and better | publisher = Wiley | location = Indianapolis, Ind | year = 2011 | isbn = 978-1-118-13345-3 | url = https://books.google.com/books?id=d-FYJceblAMC | at=Hack 29}}</ref>


=== Relationship with other methods === == Relationship with other methods ==


Timeboxing acts as a building block in other personal time management methods: Timeboxing acts as a building block in other personal time management methods:


* The ] is based on 25 minute timeboxes of focused concentration separated by breaks allowing the mind to recover.<ref>{{cite book | last=Nöteberg | first=Staffan | title=Pomodoro Technique Illustrated | publisher = Pragmatic Bookshelf | location = Raleigh, N.C | isbn=978-1-934356-50-0 }}</ref> * The ] is based on 25 minute timeboxes of focused concentration separated by breaks allowing the mind to recover.<ref>{{cite book | last=Nöteberg | first=Staffan | title=Pomodoro Technique Illustrated | year=2009 | publisher = Pragmatic Bookshelf | location = Raleigh, N.C | isbn=978-1-934356-50-0 }}</ref>
* ] gives timeboxing as his 'T' in ].<ref>{{cite book | last = Hunt | first = Andrew | title = Pragmatic thinking and learning : refactor your wetware | publisher = Pragmatic | location = Raleigh | year = 2008 | isbn = 978-1-934356-05-0 }}</ref> * ] gives timeboxing as his 'T' in ].<ref>{{cite book | last = Hunt | first = Andrew | title = Pragmatic thinking and learning: refactor your wetware | publisher = Pragmatic | location = Raleigh | year = 2008 | isbn = 978-1-934356-05-0 | url = https://archive.org/details/pragmaticthinkin00hunt_1 }}</ref>


== See also == == See also ==
* ], a time-constrained five-phase process used in design thinking.

* ]


== References == == References ==
{{reflist|30em}} {{reflist}}

== External links ==
*
*
*
*
*
*


] ]

Latest revision as of 08:12, 2 April 2024

Time management method
Part of a series on
Software development
Core activities
Paradigms and models
Methodologies and frameworks
Supporting disciplines
Practices
Tools
Standards and bodies of knowledge
Glossaries
Outlines

In agile principles, timeboxing allocates a maximum unit of time to an activity, called a timebox, within which a planned activity takes place. It is used by agile principles-based project management approaches and for personal time management.

In project management

Timeboxing is used as a project planning technique. The schedule is divided into a number of separate time periods (timeboxes), with each part having its own deliverables, deadline and budget. Sometimes referred to as schedule as independent variable (SAIV). "Timeboxing works best in multistage projects or tasks that take little time and you can fit them in the same time slot. It is also worth implementing in case of duties that have foreseeable time-frames of completion."

As an alternative to fixing scope

In project management, there are generally considered to be three constraints: time (sometimes schedule), cost (sometimes budget), and scope. (Quality is often added as a fourth constraint---represented as the middle of a triangle.) The assumption is that a change in one constraint will affect the others.

Without timeboxing, projects usually work to a fixed scope, in which case when it becomes clear that some deliverables cannot be completed within the planned timescales, either the deadline has to be extended (to allow more time to complete the fixed scope) or more people are involved (to complete the fixed scope in the same time). Often both happen, resulting in delayed delivery, increased costs, and often reduced quality (as per The Mythical Man-Month principle).

With timeboxing, the deadline is fixed, meaning that the scope would have to be reduced. As this means organizations have to focus on completing the most important deliverables first, timeboxing often goes hand-in-hand with a scheme for prioritizing of deliverables (such as with the MoSCoW method).

To manage risk

Timeboxes are used as a form of risk management, to explicitly identify uncertain task/time relationships, i.e., work that may easily extend past its deadline. Time constraints are often a primary driver in planning and should not be changed without considering project or sub-project critical paths. That is, it's usually important to meet deadlines. Risk factors for missed deadlines can include complications upstream of the project, planning errors within the project, team-related issues, or faulty execution of the plan. Upstream issues might include changes in project mission or backing/support from management. A common planning error is inadequate task breakdown, which can lead to underestimation of the time required to perform the work. Team-related issues can include trouble with inter-team communication; lack of experience or required cross-functionality; lack of commitment/drive/motivation (i.e. poor team building and management).

To stay on deadline, the following actions against the triple constraints are commonly evaluated:

  • Reduce scope: drop requirements of lower impact (the ones that will not be directly missed by the user)
  • Time is the fixed constraint here
  • Increase cost: e.g., add overtime or resources

Adoption in software development

Many successful software development projects use timeboxing, especially smaller ones. Adopting timeboxing more than tripled developer productivity at DuPont in the '80s. In some cases, applications were completely delivered within the time estimated to complete just a specification. However, Steve McConnell argues that not every product is suitable and that timeboxing should only be used after the customer agrees to cut features, not quality. There is little evidence for strong adoption amongst the largest class of projects.

Timeboxing has been adopted by some notable software development methodologies:

Agile software development advocates moving from plan driven to value driven development. Quality and time are fixed but flexibility allowed in scope. Delivering the most important features first leads to an earlier return on investment than the waterfall model.

A lack of detailed specifications typically is the result of a lack of time, or the lack of knowledge of the desired end result (solution). In many types of projects, and especially in software engineering, analyzing and defining all requirements and specifications before the start of the realization phase is impossible. Timeboxing can be a favorable type of contracting for projects in which the deadline is the most critical aspect and when not all requirements are completely specified up front. This also allows for new feedback or insights discovered during the project to be reflected in the end result.

In personal time management

Main article: Timeblocking

Timeboxing can be used for personal tasks, in which case it uses a reduced scale of time (e.g., thirty minutes) and of deliverables (e.g., a household chore instead of project deliverable), and is often called timeblocking.

Personal timeboxing is also said to act as a life hack to help curb perfectionist tendencies (by setting a firm time and not overcommitting to a task) which can also enhance creativity and focus (by creating a sense of urgency or increased pressure).

Relationship with other methods

Timeboxing acts as a building block in other personal time management methods:

  • The Pomodoro Technique is based on 25 minute timeboxes of focused concentration separated by breaks allowing the mind to recover.
  • Andy Hunt gives timeboxing as his 'T' in SMART.

See also

  • Design sprint, a time-constrained five-phase process used in design thinking.

References

  1. Boehm, Barry W.; Boehm, Barry; Turner, Richard (2004). Balancing Agility and Discipline: A Guide for the Perplexed. Addison-Wesley Professional. ISBN 9780321186126.
  2. "Timeboxing – why you should use it?". Firmbee. 2022-01-17. Retrieved 2022-01-25.
  3. What are the Triple Constraints in Project Management Archived 2006-08-20 at archive.today, article by Rod Hutchings on Project Management Australia Archived 2009-02-16 at the Wayback Machine (22 Oct 2008)
  4. Chatfield, Carl. "A short course in project management". Microsoft.
  5. Dobson, Michael (2004). The triple constraints in project management. Vienna, Va: Management Concepts. ISBN 1-56726-152-3.
  6. ^ Kanabar, Vijay (2008). MBA Fundamentals: Project Management. New York: Kaplan Pub. p. 51. ISBN 978-1-4277-9744-5.
  7. ^ Leffingwell, Dean (2011). Agile Software Requirements: Lean requirements practices for teams, programs, and the enterprise. Upper Saddle River, NJ: Addison-Wesley. pp. 17–19. ISBN 978-0-321-63584-6.
  8. Snedaker, Susan; Nels Hoenig (2005). How to Cheat at IT Project Management. Syngress. ISBN 1-59749-037-7.
  9. Beck, Kent (2000). Extreme programming eXplained: embrace change. Reading, MA: Addison-Wesley. pp. 15–19. ISBN 0-201-61641-6.
  10. Dangelo, Mark (2005). Innovative relevance: realigning the organization for profit: it is not a battle for the "shore lines" - it's a struggle for purpose. New York: iUniverse. p. 53. ISBN 978-0-595-67081-9.
  11. Godin, Seth. Getting Real: The smarter, faster, easier way to build a successful web application. 37signals.
  12. ^ Jennifer., Stapleton (1997). DSDM, dynamic systems development method: the method in practice. Harlow, England: Addison-Wesley. ISBN 0201178893. OCLC 36755892.
  13. ^ For all project types time boxing ranked 23 and rated "Very Good Practice"; for small (1000 function point) projects ranked 7 and rated a "Best Practice" by the survey in Jones, Capers (2010). Software engineering best practices lessons from successful projects in the top companies. New York: McGraw-Hill. ISBN 978-0-07-162162-5.
  14. ^ McConnell, Steve (1996). Rapid Development: taming wild software schedules. Redmond, Wash: Microsoft Press. pp. 575–583. ISBN 1-55615-900-5.
  15. Poppendieck, Mary (2010). Leading Lean Software Development: Results are not the Point. Upper Saddle River, NJ: Addison-Wesley. pp. 137–140. ISBN 978-0-321-62070-5.
  16. Coplien, James (2010). Lean Architecture for Agile Software Development. Chichester Hoboken, N.J: Wiley. p. 25. ISBN 978-0-470-68420-7.
  17. Cohn, Mike (2010). Succeeding with Agile: Software Development using Scrum. Upper Saddle River, NJ: Addison-Wesley. pp. 257–284. ISBN 978-0-321-57936-2.
  18. ^ Schwaber, Ken (2009). Agile Project Management with Scrum. New York: O'Reilly Media, Inc. ISBN 978-0-7356-3790-0.
  19. Leffingwell, Dean (2011). Agile Software Requirements: Lean requirements practices for teams, programs, and the enterprise. Upper Saddle River, NJ: Addison-Wesley. p. 15. ISBN 978-0-321-63584-6.
  20. Beck, Kent (2000). Extreme programming eXplained: embrace change. Reading, MA: Addison-Wesley. pp. 85–96. ISBN 0-201-61641-6.
  21. Pash, Adam (2011). Lifehacker the guide to working smarter, faster, and better. Indianapolis, Ind: Wiley. Hack 29. ISBN 978-1-118-13345-3.
  22. Nöteberg, Staffan (2009). Pomodoro Technique Illustrated. Raleigh, N.C: Pragmatic Bookshelf. ISBN 978-1-934356-50-0.
  23. Hunt, Andrew (2008). Pragmatic thinking and learning: refactor your wetware. Raleigh: Pragmatic. ISBN 978-1-934356-05-0.
Categories: