Scrum (software development)

Last updated

Scrum Agile events, based on The 2020 Scrum Guide Scrum Agile events.png
Scrum Agile events, based on The 2020 Scrum Guide

Scrum is an agile team collaboration framework commonly used in software development and other industries.

Contents

Scrum prescribes for teams to break work into goals to be completed within time-boxed iterations, called sprints. Each sprint is no longer than one month and commonly lasts two weeks. The scrum team assesses progress in time-boxed, stand-up meetings of up to 15 minutes, called daily scrums. At the end of the sprint, the team holds two further meetings: one sprint review to demonstrate the work for stakeholders and solicit feedback, and one internal sprint retrospective. A person in charge of a scrum team is typically called a scrum master. [2]

Scrum's approach to product development involves bringing decision-making authority to an operational level. [3] Unlike a sequential approach to product development, scrum is an iterative and incremental framework for product development. [4] Scrum allows for continuous feedback and flexibility, requiring teams to self-organize by encouraging physical co-location or close online collaboration, and mandating frequent communication among all team members. The flexible and semi-unplanned approach of scrum is based in part on the notion of requirements volatility, that stakeholders will change their requirements as the project evolves. [5]

History

The use of the term scrum in software development came from a 1986 Harvard Business Review paper titled "The New New Product Development Game" by Hirotaka Takeuchi and Ikujiro Nonaka. Based on case studies from manufacturing firms in the automotive, photocopier, and printer industries, the authors outlined a new approach to product development for increased speed and flexibility. They called this the rugby approach, as the process involves a single cross-functional team operating across multiple overlapping phases, in which the team "tries to go the distance as a unit, passing the ball back and forth". [6] The authors later developed scrum in their book, The Knowledge Creating Company. [7]

In the early 1990s, Ken Schwaber used what would become scrum at his company, Advanced Development Methods. Jeff Sutherland, John Scumniotales, and Jeff McKenna developed a similar approach at Easel Corporation, referring to the approach with the term scrum. [8] Sutherland and Schwaber later worked together to integrate their ideas into a single framework, formally known as scrum. Schwaber and Sutherland tested scrum and continually improved it, leading to the publication of a research paper in 1995, [9] and the Manifesto for Agile Software Development in 2001. [10] Schwaber also collaborated with Babatunde Ogunnaike at DuPont Research Station and the University of Delaware to develop Scrum. Ogunnaike believed that software development projects could often fail when initial conditions change, if the product management was not rooted in empirical practice. [3]

In 2002, Schwaber with others founded the Scrum Alliance and set up the Certified Scrum accreditation series. [11] Schwaber left the Scrum Alliance in late 2009 and subsequently founded Scrum.org which oversees the parallel Professional Scrum accreditation series. [12] Since 2009, a public document called The Scrum Guide [13] has been published and updated by Schwaber and Sutherland. It has been revised 6 times, with the current version being November 2020.

Scrum team

A scrum team is organized into at least three categories of individuals: the product owner, developers, and the scrum master. The product owner liaises with stakeholders, those who have interest in the project's outcome, to communicate tasks and expectations with developers. [14] Developers in a scrum team organize work by themselves, with the facilitation of a scrum master. [15] Scrum teams, ideally, should abide by the five values of scrum: commitment, courage, focus, openness, and respect. [13]

Product owner

Each scrum team has one product owner. [16] The product owner focuses on the business side of product development and spends the majority of time liaising with stakeholders and the team. The role is intended to primarily represent the product's stakeholders, the voice of the customer, or the desires of a committee, and bears responsibility for the delivery of business results. [17] [18] [19] [20] Product owners manage the product backlog, which is essentially the project's running to-do list, and are responsible for maximizing the value that a team delivers. [18] They do not dictate the technical solutions of a team but may instead attempt to seek consensus among team members. [21] [22]

As the primary liaison of the scrum team towards stakeholders, product owners are responsible for communicating announcements, project definitions and progress, RIDAs (risks, impediments, dependencies, and assumptions), funding and scheduling changes, the product backlog, and project governance, among other responsibilities. [23] [ better source needed ] Product owners can also cancel a sprint if necessary, without the input of team members. [13]

Developers

In scrum, the term developer or team member refers to anyone who plays a role in the development and support of the product and can include researchers, architects, designers, programmers, etc. [13] [24]

Scrum master

Scrum is facilitated by a scrum master, whose role is to educate and coach teams about scrum theory and practice. [1] Scrum masters have differing roles and responsibilities from traditional team leads or project managers. Some scrum master responsibilities include coaching, objective setting, problem solving, oversight, planning, backlog management, and communication facilitation. [1] On the other hand, traditional project managers often have people management responsibilities, which a scrum master does not. Scrum teams do not involve project managers, so as to maximize self-organisation among developers. [25]

Workflow

Sprint

The scrum framework (PBI in the figure refers to product backlog item) Scrum Framework.png
The scrum framework (PBI in the figure refers to product backlog item)
The scrum process Scrum process.svg
The scrum process

A sprint (also known as an iteration , timebox or design sprint ) is a fixed period of time wherein team members work on a specific goal. Each sprint is normally between one week and one month, with two weeks being the most common. [3] Usually, daily meetings are held to discuss the progress of the project undertaken as well as difficulties faced by team members. The outcome of the sprint is a functional deliverable, or a product which has received some development in increments.

When a sprint is abnormally terminated, the next step is to conduct new sprint planning, where the reason for the termination is reviewed.

Each sprint starts with a sprint planning event in which a sprint goal is defined. Priorities for planned sprints are chosen out of the backlog. Each sprint ends with two events: [8]

Scrum emphasizes actionable output at the end of each sprint, which brings the developed product closer to market success.

Sprint planning

At the beginning of a sprint, the scrum team holds a sprint planning event to:

The suggested maximum duration of sprint planning is eight hours for a four-week sprint. [13]

Daily scrum

A daily scrum in the computing room. This centralized location helps the team start on time. Daily sprint meeting.jpg
A daily scrum in the computing room. This centralized location helps the team start on time.

Each day during a sprint, the developers hold a daily scrum (often conducted standing up) with specific guidelines, and which may be facilitated by a scrum master. [3] [26] Daily scrum meetings are intended to be less than 15 minutes in length, taking place at the same time and location daily. The purpose of the meeting is to announce progress made towards the sprint goal and issues that may be hindering the goal, without going into any detailed discussion. Once over, individual members can go into a 'breakout session' or an 'after party' for extended discussion and collaboration. [27] Scrum masters are responsible for ensuring that team members use daily scrums effectively, or, if team members are unable to use them, to provide alternatives to achieve similar outcomes. [28] [29]

Post-sprint events

Conducted at the end of a sprint, a sprint review is a meeting that has a team share the work they've completed with stakeholders and liaise with them on feedback, expectations, and upcoming plans. At a sprint review completed deliverables are demonstrated to stakeholders, who should also be made aware of product increments and works in progress. The recommended duration for a sprint review is one hours per week of sprint. [13]

A sprint retrospective is a separate meeting that allows team members to internally analyze strengths and weaknesses of the sprint, future areas of improvement, and continuous process improvement actions. [30]

Backlog refinement

Backlog refinement is a process by which team members revise and prioritize a backlog for future sprints. [31] It can be done as a separate stage done before the beginning of a new sprint or as a continuous process that team members work on by themselves. Backlog refinement can include the breaking down of large tasks into smaller and clearer ones, the clarification of success criteria, and the revision of changing priorities and returns. It is recommended to invest of up to 10 percent of a team's sprint capacity on backlog refinement. [13]

Artifacts

Artifacts are a means by which scrum teams manage product development by documenting work done towards the project. The main scrum artifacts used are the product backlog, sprint backlog, and increment.

Product backlog

The product backlog is a breakdown of work to be done and contains an ordered list of product requirements (such as features, bug fixes, non-functional requirements) that the team maintains for a product. The order of a product backlog corresponds to the urgency of the task. Common formats for backlog items include user stories and use cases. [25] The product backlog may also contain the product owner's assessment of business value and the team's assessment of the product's effort or complexity, which can be stated in story points using the rounded Fibonacci scale. These estimates help the product owner to gauge the timeline and may influence the ordering of product backlog items. [32]

The product owner maintains and prioritizes product backlog items based on considerations such as risk, business value, dependencies, size, and timing. High-priority items at the top of the backlog are broken down into more detail for developers to work on, while tasks further down the backlog may be more vague. [3]

Sprint backlog

The sprint backlog is the subset of items from the product backlog intended for developers to address in a particular sprint. [33] Developers fill this backlog with tasks they deem appropriate to fill the sprint, using past performance to assess their capacity for each sprint. The scrum approach has tasks on the sprint backlog not assigned to developers by any particular individual or leader. Team members self organize by pulling work as needed according to the backlog priority and their own capabilities and capacity. [34]

Increment

An increment is a potentially releasable output of a sprint, which meets the sprint goal. It is formed from all the completed sprint backlog items, integrated with the work of all previous sprints. An ideal increment is complete, fully functioning, and in a usable condition.

Other artifacts

Burndown chart

A sample burndown chart for a completed sprint, showing remaining effort at the end of each day. SampleBurndownChart.svg
A sample burndown chart for a completed sprint, showing remaining effort at the end of each day.

Often used in scrum, a burndown chart is a publicly displayed chart showing remaining work. [35] Updated every day, it provides quick visualizations for reference. The horizontal axis of the burndown chart shows the days remaining, while the vertical axis shows the amount of work remaining each day. During sprint planning, the ideal burndown chart is plotted. Then, during the sprint, developers update the chart with remaining work so the chart is updated day by day, showing a comparison between actual and predicted.

Release burn-up chart

A sample burn-up chart for a release, showing scope completed each sprint (MVP = Minimum Viable Product) SampleBurnupChart.png
A sample burn-up chart for a release, showing scope completed each sprint (MVP = Minimum Viable Product)

Updated at the end of each sprint, the release burn-up chart shows progress towards delivering a forecast scope. The horizontal axis of the release burn-up chart shows the sprints in a release, while the vertical axis shows the amount of work completed at the end of each sprint.

Velocity

Some project managers believe that a team's total capability effort for a single sprint can be derived by evaluating work completed in the last sprint. The collection of historical "velocity" data is a guideline for assisting the team in understanding their capacity. Nonetheless, the concept of velocity has been controversial among scrum practitioners.

Limitations

Some have argued that scrum events, such as daily scrum and scrum review, hurt productivity and waste time that could be better spent on actual productive tasks. [36] [37] In practice, many scrum practitioners conduct events, like the daily scrum, as an extended discussion, without complying with the time-boxing requirement.[ citation needed ]

Scrum has also been observed to pose difficulties for a number of types of teams, including those which are part-time or geographically distant; which have members that are highly specialized and would be better off working by themselves or in working cliques; which have many external dependencies that disrupt planned short sprints of work from occurring; and which are unsuitable for incremental and development testing. [38] [39]

Adaptations

Scrum is frequently tailored or adapted in different contexts to achieve varying aims. [40] A common approach to adapting scrum is the combination of scrum with other software development methodologies, as scrum does not cover the whole product development lifecycle. [41] Various scrum practitioners have also suggested more detailed techniques for how to apply or adapt scrum to particular problems or organizations. Many refer to these techniques as 'patterns', an analogous use to design patterns in architecture and software. [42] [43]

Scrumban

Scrumban is a software production model based on scrum and kanban. To illustrate each stage of work, teams working in the same space often use post-it notes or a large whiteboard. [44] Scrumban is especially suited for product maintenance with frequent and unexpected work items, such as production defects or programming errors. In such cases time-limited scrum sprints may not be as beneficial, although scrum's daily events and other practices can still be applied. At the same time, kanban models allow a team to visualize work stages and limitations. [45]

Scrum of scrums

Scrum of scrums is a technique to operate scrum at scale, for multiple teams coordinating on the same product. Scrum-of-scrums daily scrum meetings involve ambassadors selected from each individual team, who may be either a developer or scrum master. As a tool for coordination, scrum of scrums allows teams to collectively work on team-wide risks, impediments, dependencies, and assumptions (RIDAs), which may be tracked in a backlog of its own. [46] [47]

Large-scale scrum

Large-scale scrum is a product development framework that scales scrum with varied rules and guidelines, developed by Bas Vodde and Craig Larman. [48] [49] There are two levels to the framework: the first level, designed for up to eight teams; and the second level, known as 'LeSS Huge', which can accommodate development involving hundreds of developers. [50]

Criticism

A systematic review found "that Distributed Scrum has no impact, positive or negative on overall project success" in distributed software development. [51]

Martin Fowler, one of the authors of the Manifesto for Agile Software Development, has criticised what he calls "faux-agile" practices that are "disregarding agile's values and principles", [52] and "the Agile Industrial Complex imposing methods upon people" contrary to the Agile principle of valuing "individuals and interactions over processes and tools" [10] and allowing the individuals doing the work to decide how the work is done, changing processes to suit their needs.

In Sept 2016 Ron Jeffries, a signatory to the Agile Manifesto, [53] posted about what he called "Dark Scrum" saying that "Scrum can be very unsafe for programmers." Ron is saying Scrum as a system creates unrealistic expectations and resulting in blame rather than improvement. [54]

See also

Citations

  1. 1 2 3 Ken Schwaber; Jeff Sutherland. "The Scrum Guide" (PDF). Scrum.org. Retrieved June 15, 2023.
  2. ↑ "What Is A Scrum Master? Everything You Need To Know – Forbes Advisor". www.forbes.com. Retrieved November 16, 2023.
  3. 1 2 3 4 5 Schwaber, Ken (February 1, 2004). Agile Project Management with Scrum . Microsoft Press. ISBN   978-0-7356-1993-7.
  4. ↑ "What is Scrum?". What is Scrum? An Agile Framework for Completing Complex Projects – Scrum Alliance. Scrum Alliance. Retrieved February 24, 2016.
  5. ↑ J. Henry and S. Henry. Quantitative assessment of the software maintenance process and requirements volatility. In Proc. of the ACM Conference on Computer Science, pages 346–351, 1993.
  6. ↑ Takeuchi, Hirotaka; Nonaka, Ikujiro (January 1, 1986). "The New New Product Development Game". Harvard Business Review. Retrieved June 9, 2010. Moving the Scrum Downfield
  7. ↑ The Knowledge Creating Company. Oxford University Press. 1995. p. 3. ISBN   978-0-19-976233-0 . Retrieved March 12, 2013.
  8. 1 2 Sutherland, Jeff (October 2004). "Agile Development: Lessons learned from the first Scrum". Archived from the original (PDF) on June 30, 2014. Retrieved September 26, 2008.
  9. ↑ Sutherland, Jeffrey Victor; Schwaber, Ken (1995). Business object design and implementation: OOPSLA '95 workshop proceedings. The University of Michigan. p. 118. ISBN   978-3-540-76096-2.
  10. 1 2 "Manifesto for Agile Software Development" . Retrieved October 17, 2019.
  11. ↑ Maximini, Dominik (January 8, 2015). The Scrum Culture: Introducing Agile Methods in Organizations. Management for Professionals. Cham: Springer (published 2015). p. 26. ISBN   978-3-319-11827-7 . Retrieved August 25, 2016. Ken Schwaber and Jeff Sutherland presented Scrum for the first time at the OOPSLA conference in Austin, Texas, in 1995. [...] In 2001, the first book about Scrum was published. [...] One year later (2002), Ken founded the Scrum Alliance, aiming at providing worldwide Scrum training and certification.
  12. ↑ "Home". Scrum.org. Retrieved January 6, 2020.
  13. 1 2 3 4 5 6 7 Sutherland, Jeff; Schwaber, Ken (2013). "Scrum Guides". ScrumGuides.org. Retrieved June 15, 2023.
  14. ↑ Morris, David (2017). Scrum: an ideal framework for agile projects. In Easy Steps. pp. 178–179. ISBN   978-1-84078-731-3. OCLC   951453155.
  15. ↑ Cobb, Charles G. (2015). The Project Manager's Guide to Mastering Agile: Principles and Practices for an Adaptive Approach. Hoboken, NJ: John Wiley & Sons. p. 37. ISBN   978-1-118-99104-6.
  16. ↑ Cohn, Mike (2010). Succeeding with Agile: Software Development Using Scrum. Upper Saddle River, NJ: Addison-Wesley. ISBN   978-0-321-57936-2.
  17. ↑ Rubin, Kenneth (2013), Essential Scrum. A Practical Guide to the Most Popular Agile Process, Addison-Wesley, p. 173, ISBN   978-0-13-704329-3
  18. 1 2 McGreal, Don; Jocham, Ralph (June 4, 2018). The Professional Product Owner: Leveraging Scrum as a Competitive Advantage. Addison-Wesley Professional. ISBN   978-0-13-468665-3.
  19. ↑ Pichler, Roman (March 11, 2010). Agile Product Management with Scrum: Creating Products that Customers Love. Addison-Wesley Professional. ISBN   978-0-321-68413-4.
  20. ↑ Ambler, Scott. "The Product Owner Role: A Stakeholder Proxy for Agile Teams". agilemodeling.com. Retrieved July 22, 2016. [...] in practice there proves to be two critical aspects to this role: first as a stakeholder proxy within the development team and second as a project team representative to the overall stakeholder community as a whole.
  21. ↑ "The Scrum Guide" (PDF). Scrum.org. p. 6. Retrieved June 15, 2023.
  22. ↑ "The Role of the Product Owner". Scrum Alliance. Retrieved May 26, 2018.
  23. ↑ "The Product Owner Role". Scrum Master Test Prep. Retrieved February 3, 2017.
  24. ↑ Rad, Nader K.; Turley, Frank (2018). Agile Scrum Foundation Courseware, Second Edition. 's-Hertogenbosch, Netherlands: Van Haren. p. 26. ISBN   978-94-018-0279-6.
  25. 1 2 Pete Deemer; Gabrielle Benefield; Craig Larman; Bas Vodde (December 17, 2012). "The Scrum Primer: A Lightweight Guide to the Theory and Practice of Scrum (Version 2.0)". InfoQ.
  26. ↑ "What is a Daily Scrum?". Scrum.org. Retrieved January 6, 2020.
  27. ↑ Flewelling, Paul (2018). The Agile Developer's Handbook: Get more value from your software development: get the best out of the Agile methodology. Birmingham, UK: Packt Publishing Ltd. p. 91. ISBN   978-1-78728-020-5.
  28. ↑ McKenna, Dave (2016). The Art of Scrum: How Scrum Masters Bind Dev Teams and Unleash Agility. Aliquippa, PA: CA Press. p. 126. ISBN   978-1-4842-2276-8.
  29. ↑ Drongelen, Mike van; Dennis, Adam; Garabedian, Richard; Gonzalez, Alberto; Krishnaswamy, Aravind (2017). Lean Mobile App Development: Apply Lean startup methodologies to develop successful iOS and Android apps. Birmingham, UK: Packt Publishing Ltd. p. 43. ISBN   978-1-78646-704-1.
  30. ↑ Rubin, Kenneth (2012), Essential Scrum. A Practical Guide to the Most Popular Agile Process, Addison-Wesley (published 2013), p. 375, ISBN   978-0-13-704329-3
  31. ↑ Project Management Institute 2021, Glossary §3 Definitions.
  32. ↑ Higgins, Tony (March 31, 2009). "Authoring Requirements in an Agile World". BA Times.
  33. ↑ Russ J. Martinelli; Dragan Z. Milosevic (January 5, 2016). Project Management ToolBox: Tools and Techniques for the Practicing Project Manager. Wiley. p. 304. ISBN   978-1-118-97320-2.
  34. ↑ Ken Schwaber; Jeff Sutherland. "The Scrum Guide" (PDF). Scrum.org. Retrieved May 25, 2018.
  35. ↑ Charles G. Cobb (January 27, 2015). The Project Manager's Guide to Mastering Agile: Principles and Practices for an Adaptive Approach. John Wiley & Sons. p. 378. ISBN   978-1-118-99104-6.
  36. ↑ Jenson, John (March 8, 2019). "Meetings: The productivity killer for developers". TandemSeven – The Experience Innovation Company. Archived from the original on June 5, 2020. Retrieved June 5, 2020.
  37. ↑ "Not all developers like agile, and here are 5 reasons why". Business Matters. December 4, 2019. Retrieved June 5, 2020.
  38. ↑ Turk, Dan; France, Robert; Rumpe, Bernhard (2014) [2002]. "Limitations of Agile Software Processes". Proceedings of the Third International Conference on Extreme Programming and Flexible Processes in Software Engineering: 43–46. arXiv: 1409.6600 .
  39. ↑ "Issues and Challenges in Scrum Implementation" (PDF). International Journal of Scientific & Engineering Research. 3 (8). August 2012. Retrieved December 10, 2015.
  40. ↑ Hron, Michal; Obwegeser, Nikolaus (January 1, 2022). "Why and how is Scrum being adapted in practice: A systematic review". Journal of Systems and Software. 183: 111110. doi:10.1016/j.jss.2021.111110. ISSN   0164-1212. S2CID   240950847.
  41. ↑ Hron, M.; Obwegeser, N. (January 2018). "Scrum in practice: an overview of Scrum adaptations" (PDF). Proceedings of the 2018 51st Hawaii International Conference on System Sciences (HICSS), January 3–6, 2018.
  42. ↑ Bjørnvig, Gertrud; Coplien, Jim (June 21, 2008). "Scrum as Organizational Patterns". Gertrude & Cope.
  43. ↑ "Scrum Pattern Community". ScrumPLoP.org. Retrieved July 22, 2016.
  44. ↑ Ladas, Corey (October 27, 2007). "scrum-ban". Lean Software Engineering. Archived from the original on August 23, 2018. Retrieved September 13, 2012.
  45. ↑ Kniberg, Henrik; Skarin, Mattias (December 21, 2009). "Kanban and Scrum – Making the most of both" (PDF). InfoQ. Retrieved July 22, 2016.
  46. ↑ "Risk Management – How to Stop Risks from Screwing Up Your Projects!". Kelly Waters.
  47. ↑ "Scrum of Scrums". Agile Alliance. December 17, 2015. Archived from the original on February 9, 2014. Retrieved December 17, 2013.
  48. ↑ "Large-Scale Scrum (LeSS)". 2014.
  49. ↑ Grgic (2015). "Descaling organisation with LeSS (Blog)".
  50. ↑ Larman, Craig; Bas Vodde (May–June 2013). "Scaling Agile Development" (PDF). Crosstalk.
  51. ↑ Santos, Ronnie de Souza; Ralph, Paul; Arshad, Arham; Stol, Klaas-Jan (October 5, 2023). "Distributed Scrum: A Case Meta-Analysis". ACM Computing Surveys. doi: 10.1145/3626519 . S2CID   263672588.
  52. ↑ Fowler, Martin (August 25, 2018). "The State of Agile Software in 2018". martinfowler.com. Archived from the original on September 14, 2023. Retrieved September 14, 2023.
  53. ↑ https://agilemanifesto.org/authors.html
  54. ↑ https://ronjeffries.com/articles/016-09ff/defense/

Related Research Articles

In software development, a lead programmer is responsible for providing technical guidance and mentorship to a team of software developers. Alternative titles include development lead, technical lead, lead programmer, or lead application developer. When primarily contributing a low-level enterprise software design with focus on the structure of the app, e.g. design patterns, the role would be a software architect

Agile software development is the mindset for developing software that derives from values agreed upon by The Agile Alliance, a group of 17 software practitioners in 2001. As documented in their Manifesto for Agile Software Development the practitioners value:

<span class="mw-page-title-main">Craig Larman</span> Canadian-born computer scientist, author, and organizational development consultant

Craig Larman is a Canadian computer scientist, author, and organizational development consultant. With Bas Vodde, he is best known for formulating LeSS, and for several books on product and software development.

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.

<span class="mw-page-title-main">Ken Schwaber</span> American computer scientist

Ken Schwaber is a software developer, product manager and industry consultant. He worked with Jeff Sutherland to formulate the initial versions of the Scrum framework and to present Scrum as a formal process at OOPSLA'95. Schwaber and Sutherland are two of the 17 initial signatories of the Agile Manifesto. They are co-authors of the Scrum Guide. Schwaber runs Scrum.org, which provides Scrum resources, training, assessments, and certifications for Scrum Masters, Scrum Developers, Scrum Product Owners, and organizations using Scrum.

Agile modeling (AM) is a methodology for modeling and documenting software systems based on best practices. It is a collection of values and principles that can be applied on an (agile) software development project. This methodology is more flexible than traditional modeling methods, making it a better fit in a fast-changing environment. It is part of the agile software development tool kit.

A product manager (PM) is a professional role that is responsible for the development of products for an organization, known as the practice of product management. Product managers own the product strategy behind a product, specify its functional requirements, and manage feature releases. Product managers coordinate work done by many other functions, and are ultimately responsible for product outcomes.

<span class="mw-page-title-main">Jeff Sutherland</span> American computer scientist

Jeff Sutherland is one of the creators of Scrum, a framework for product management. Together with Ken Schwaber, he presented Scrum at OOPSLA'95. Sutherland contributed to the creation of the Agile Manifesto in 2001. Along with Ken Schwaber, he wrote and maintains The Scrum Guide, which contains the official definition of the framework.

A stand-up meeting (stum) is a meeting in which attendees typically participate while standing. The discomfort of standing for long periods is intended to keep the meetings short.

In software engineering, a software development process or software development life cycle (SDLC) is a process of planning and managing software development. It typically involves dividing software development work into smaller, parallel, or sequential steps or sub-processes to improve design and/or product management. The methodology may include the pre-definition of specific deliverables and artifacts that are created and completed by a project team to develop or maintain an application.

The INVEST mnemonic for Agile software development projects was created by Bill Wake as a reminder of the characteristics of a good quality Product Backlog Item or PBI for short. Such PBIs may be used in a Scrum backlog, Kanban board or XP project.

ScrumEdge is a collaborative web-based scrum tool that allows agile development teams, ScrumMasters, and stakeholders to manage the Scrum lifecycle at the product and sprint levels.

<span class="mw-page-title-main">Kanban (development)</span> Software development methodology

Kanban is a lean method to manage and improve work across human systems. This approach aims to manage work by balancing demands with available capacity, and by improving the handling of system-level bottlenecks.

Specification by example (SBE) is a collaborative approach to defining requirements and business-oriented functional tests for software products based on capturing and illustrating requirements using realistic examples instead of abstract statements. It is applied in the context of agile software development methods, in particular behavior-driven development. This approach is particularly successful for managing requirements and functional tests on large-scale projects of significant domain and organisational complexity.

Disciplined agile delivery (DAD) is the software development portion of the Disciplined Agile Toolkit. DAD enables teams to make simplified process decisions around incremental and iterative solution delivery. DAD builds on the many practices espoused by advocates of agile software development, including scrum, agile modeling, lean software development, and others.

eXtreme Manufacturing (XM) is an iterative and incremental framework for manufacturing improvement and new product development that was inspired by the software development methodology Scrum and the systematic waste-elimination (lean) production scheduling system Kanban(かんばん ).

Within agile project management, product backlog refers to a prioritized list of functionality which a product should contain. It is sometimes referred to as a to-do list, and is considered an 'artifact' within the scrum software development framework. The product backlog is referred to with different names in different project management frameworks, such as product backlog in scrum, work item list in disciplined agile, and option pool in lean. In the scrum framework, creation and continuous maintenance of the product backlog is part of the responsibility of the product owner.

The scaled agile framework (SAFe) is a set of organization and workflow patterns intended to guide enterprises in scaling lean and agile practices. Along with disciplined agile delivery (DAD) and S@S (Scrum@Scale), SAFe is one of a growing number of frameworks that seek to address the problems encountered when scaling beyond a single team.

Agile learning generally refers to the transfer of agile methods of project work, especially Scrum, to learning processes. Likewise, agile learning proceeds in incremental steps and through an Iterative design which alternates between phases of learning and doing. The tutors rather have the role of a learning attendant or supporter. In a narrower sense, it is intended to allow competence-oriented, media-based learning in the work process within companies. In addition, the term can take several other meanings and is also often used within e-learning and online environments.

<span class="mw-page-title-main">Mike Beedle</span> American software engineer

Miguel "Mike" Beedle was an American software engineer and theoretical physicist who was a co-author of the Agile Manifesto.

References

This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.