{"id":23902734,"url":"https://github.com/mtumilowicz/scrum-notes","last_synced_at":"2026-02-07T23:05:08.470Z","repository":{"id":110879291,"uuid":"282001864","full_name":"mtumilowicz/scrum-notes","owner":"mtumilowicz","description":null,"archived":false,"fork":false,"pushed_at":"2020-10-18T15:20:01.000Z","size":753,"stargazers_count":1,"open_issues_count":0,"forks_count":0,"subscribers_count":0,"default_branch":"master","last_synced_at":"2025-07-27T14:57:16.946Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/mtumilowicz.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null}},"created_at":"2020-07-23T16:25:53.000Z","updated_at":"2021-07-21T20:19:51.000Z","dependencies_parsed_at":"2023-03-13T03:01:37.024Z","dependency_job_id":null,"html_url":"https://github.com/mtumilowicz/scrum-notes","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/mtumilowicz/scrum-notes","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/mtumilowicz%2Fscrum-notes","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/mtumilowicz%2Fscrum-notes/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/mtumilowicz%2Fscrum-notes/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/mtumilowicz%2Fscrum-notes/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/mtumilowicz","download_url":"https://codeload.github.com/mtumilowicz/scrum-notes/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/mtumilowicz%2Fscrum-notes/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":29211656,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-02-07T22:58:45.823Z","status":"ssl_error","status_checked_at":"2026-02-07T22:58:45.272Z","response_time":63,"last_error":"SSL_read: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2025-01-04T22:50:13.983Z","updated_at":"2026-02-07T23:05:08.465Z","avatar_url":"https://github.com/mtumilowicz.png","language":null,"funding_links":[],"categories":[],"sub_categories":[],"readme":"* references\n    * https://www.scrumguides.org/scrum-guide.html\n    * https://www.classmarker.com/online-test/start/?quiz=vek54a6ec10658ef (multiple times)\n    * https://www.classmarker.com/online-test/start/?quiz=k6c5408cb891729e (multiple times)\n    * https://www.classmarker.com/online-test/start/?quiz=grx55b93a4d40895 (multiple times)\n    * https://mlapshin.com/index.php/scrum-quizzes/sm-learning-mode/\n    * https://www.exam4training.com/how-should-a-development-team-deal-with-non-functional-requirements-3/\n    * https://chercher.tech/agile-certification/scrum-master-certification-prep-questions-set-1\n        * set 1 - 16\n\n# scrum-notes\n* authors: Ken Schwaber, Jeff Sutherland\n    * two of the 17 initial signatories of the Agile Manifesto\n* purpose of the Scrum Guide\n    * framework for developing, delivering, and sustaining complex products\n    \n## introduction\n* since the early 1990s\n* Scrum is not: process, technique, definitive method\n    * is rather: framework within you can employ various processes and techniques\n    * framework for dealing with complexity\n    * framework for optimizing decision making (based on the knowledge and experience of the entire team)\n* used in\n    * research, technologies, product capabilities\n    * develop, sustain and renew products\n        * release as frequently as many times per day\n    * almost everything we use in our daily lives\n* especially effective in iterative and incremental knowledge transfer\n* essence of Scrum is a small team of people\n    * small team is highly flexible and adaptive\n* scrum values\n    * commitment, courage, focus, openness and respect\n    * trust: transparency, inspection, and adaptation\n    \n## Scrum Theory\n* founded on empiricism\n* employs an iterative, incremental approach to optimize predictability and control risk\n* Scrum is meant to be implemented as prescribed in the Scrum Guide\n    * five events in the Scrum Guide are mandatory - each has a specific purpose\n* three pillars\n    * transparency\n        * aspects of the process are visible to those responsible for the outcome\n        * aspects of the process defined by a common standard\n            * example - definition of \"Done\"\n    * inspection\n        * by skilled inspectors\n        * inspect artifacts and progress toward a Sprint Goal \n        * inspection should not slow down the work\n    * adaptation\n        * caused by inspection, when\n            * resulting product will be unacceptable\n            * some aspects deviate outside acceptable limits\n        * must be made as soon as possible\n    * events for inspection and adaptation\n        * Planning\n        * Daily\n        * Review\n        * Retrospective\n* role of Management in Scrum\n    * supports the Product Owner with insights and information into high value product \n    and system capabilities\n    * supports the Scrum Master to cause organizational change that fosters empiricism, \n    self-organization, bottom-up intelligence, and intelligent release of software\n    \n## Scrum Team\n* designed to optimize flexibility, creativity, and productivity\n* consists of\n    * Scrum Master (manages the process)\n    * Product Owner (decides what to do)\n    * Development Team (does the work)\n    * Product Owner or the Scrum Master can do development work\n        * it is not the best practice because it could create a conflict of interest\n* self-organizing - not directed by others outside the team\n    * chooses how to accomplish their work\n* cross-functional\n    * has all competencies\n* deliver products iteratively and incrementally, maximizing opportunities for feedback\n\n### Product Owner\n* is one person\n* responsible for maximizing the value of the product and the work of the Development Team\n* sole person responsible for managing the Product Backlog\n    * PO may have the Development Team do it, but remains accountable\n    * clearly expressing Product Backlog items\n    * assigning priorities to items\n    * ensuring that PB is visible, transparent, and clear to all\n    * ensuring the Development Team understands items\n* knows the most about the progress toward a business objective or a release, and be able to \nexplain the alternatives most clearly\n    \n### Development Team\n* only Development Team create the Increment\n* self-organizing\n    * knows how to turn Product Backlog into Increments\n* cross-functional\n    * has all the skills to create an Increment\n* no titles for members\n* no sub-teams\n* size: 3-9 - Product Owner and Scrum Master roles are not included\n    * small enough to remain nimble and large enough to complete significant work within a Sprint\n\n### Scrum Master\n* helps everyone understand Scrum theory, practices, rules, and values\n* facilitates Scrum events\n* servant-leader for the Scrum Team\n* helps those outside the Scrum Team understand which of their interactions with the Scrum Team \nare helpful and which aren’t\n    * helps change these interactions to maximize the value\n* works with the Scrum Team and the organization to increase the transparency of the artifacts\n    * ensures that artifacts are understood by everyone on the Scrum Team\n* service to Product Owner\n    * understands product planning in an empirical environment\n    * finds techniques for effective Product Backlog management\n    * understands and practice agility\n* service to the Development Team\n    * coaching in self-organization and cross-functionality\n    * removes impediments to the Development Team’s progress\n    * helps the Development Team to create high-value products\n    * teach to keep the Daily Scrum within the 15 minute time-box\n        * ensures that the Development Team has the meeting\n        * ensures that the others do not disrupt the meeting\n* service to the Organization\n    * coaching in Scrum adoption\n    * plans Scrum implementations within the organization\n    * helps stakeholders understand and enact Scrum product management\n    * causing change that increases the productivity of the Scrum Team\n    * cooperates with other Scrum Masters to increase the effectiveness of the application of Scrum\n    * is responsible for promoting and supporting Scrum as defined in the Scrum Guide\n    \n## Scrum Events\n* every event in Scrum, besides the Sprint which is a container for the other events, is an opportunity \nto Inspect and Adapt\n\n### Sprint\n* time-box: \u003c= month\n    * may be considered a project with no more than a one-month horizon\n    * when too long complexity may rise, and risk may increase\n    * limits risk to one calendar month of cost\n    * short enough to keep the business risk acceptable to the Product Owner\n    * short enough to be able to synchronize the development work with other business events\n* new Sprint starts immediately after the conclusion of the previous Sprint\n* once a Sprint begins, its duration cannot be changed\n* used to accomplish something\n* during it - \"Done\", useable, product Increment is created\n* consist of\n    * Planning\n    * Daily Scrums\n    * the development work\n    * Review\n    * Retrospective\n* no changes are made that would endanger the Sprint Goal\n* quality goals do not decrease\n* scope may be clarified and re-negotiated as more is learned: Product Owner \u003c-\u003e Development Team\n* enables predictability by ensuring inspection and adaptation of progress toward a Sprint Goal \n* cancelling a Sprint\n    * Product Owner authority\n    * only ongoing sprint\n    * if it no longer makes sense given the circumstances\n        * for example - if the Sprint Goal becomes obsolete\n    * any completed and \"Done\" Product Backlog items are reviewed\n        * incomplete Items are re-estimated and put back on the Product Backlog\n* at the end of a Sprint, the new Increment must be \"Done\"\n    * in useable condition\n        * regardless of whether the Product Owner decides to release it\n* Development Team during the first Sprint\n    * develops and delivers at least one piece of functionality\n    * delivers an increment of potentially releasable software\n           \n### Planning\n* time-boxed: \u003c= eight hours for a one-month Sprint\n* attendees: Scrum Team\n    * Development Team may invite other people to attend to provide technical or domain advice\n* input to this meeting\n    * Product Backlog\n    * latest product Increment\n    * projected capacity of the Development Team\n    * past performance of the Development Team\n* answers the question: what can be done?\n    * Product Owner discusses the objective that the Sprint should achieve and the Product Backlog \n    items that would achieve the Sprint Goal\n    * number of items selected is solely up to the Development Team\n        * only the Development Team can assess what it can accomplish\n    * Scrum Team crafts a Sprint Goal\n* how will the chosen work get done?\n    * Sprint Backlog = Product Backlog items selected for this Sprint + the plan for delivering\n    * by the end of planning: Development Team decomposes work planned for the first days\n        * often to units of one day or less\n* by the end of the Sprint Planning, the Development Team should be able to explain to the\n  Product Owner and Scrum Master how it intends to work as a self-organizing team to\n  accomplish the Sprint Goal and create the anticipated Increment\n\n### Sprint Goal\n* created during the Sprint Planning meeting\n* is an objective that can be met through the implementation of Product Backlog\n* provides guidance to the Development Team on why it is building the Increment\n* causes the Development Team to work together rather than on separate initiatives\n\n### Daily Scrum\n* time-boxed: \u003c= 15 min\n    * it does not change with the length of a Sprint\n* is a key inspect and adapt meeting\n* internal meeting for the Development Team\n    * Development Team is responsible for conducting the Daily Scrum\n    * Scrum Master ensures that others (if any) do not disrupt the meeting\n* held every day of the Sprint\n* forecasts upcoming work\n* plans work for the next 24 hours\n* optimizes team collaboration and performance by inspecting the work since the last Daily Scrum\n* is held at the same time and place each day to reduce complexity\n* inspects progress toward the Sprint Goal\n* inspects how progress is trending toward completing the work in the Sprint Backlog\n* optimizes the probability that the Development Team will meet the Sprint Goal\n* questions\n    * what did I do yesterday that helped the Development Team meet the Sprint Goal?\n    * what will I do today to help the Development Team meet the Sprint Goal?\n    * do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?\n* Development Team or team members often meet immediately after the Daily Scrum for\n  detailed discussions, or to adapt, or replan\n* pros\n    * improves communications\n    * eliminates other meetings\n    * identifies impediments to development\n    * highlights and promotes quick decision-making\n    * improves the Development Team’s level of knowledge\n\n### Review\n* time-box: \u003c= 4h for one-month Sprints\n* attendees: Scrum Team + key stakeholders invited by the Product Owner\n* Scrum Team and stakeholders inspect the outcome of a Sprint and figure out what to do next\n* held at the end of the Sprint\n    * inspect: Increment\n    * adapt: Product Backlog (if needed)\n* Scrum Team and stakeholders collaborate about what was done\n* presentation of the Increment, feedback\n    * is an informal meeting, not a status meeting\n* entire group collaborates on what to do next\n    * valuable input to subsequent Planning\n* review of the timeline, budget, potential capabilities, and marketplace\n* result of the Sprint Review is a revised Product Backlog\n* roles\n    * Product Owner\n        * explains what items have been \"Done\" and what has not been \"Done\"\n        * discusses the Product Backlog\n        * if needed: projects likely target and delivery dates based on progress\n    * Development Team\n        * discusses what went well\n        * discusses problems and how were solved\n        * demonstrates the \"Done\" work\n        * answers questions about the Increment\n\n### Retrospective\n* time-boxed: \u003c= 3h for one-month Sprints\n* attendees: Scrum Team\n    * Product Owner must be present\n* occurs after the Review and prior to the next Planning\n* inspect how the last Sprint went\n    * regards to people, relationships, process, and tools\n* create a plan for implementing improvements in the next Sprint\n    * adaptation to the inspection of the Scrum Team itself\n* identify and order the major items that went well and potential improvements\n\n## Scrum Artifacts\n* designed to maximize transparency of key information\n* are Product Backlog, Sprint Backlog and Increment\n\n### Product Backlog\n* Product Owner responsibility\n    * including content, availability, and ordering\n    * items can be updated at any time by the Product Owner or at the Product Owner’s discretion\n* product have one Product Backlog, regardless of how many teams are used\n* used to describe the upcoming work on the product\n* ordered list of everything that is known to be needed in the product\n    * lists all features, functions, requirements, enhancements, and fixes\n    * items have the attributes of a description, order, estimate, and value\n        * often include test descriptions that will prove its completeness when \"Done\"\n    * higher ordered Product Backlog items are usually clearer\n* single source of requirements for any changes to be made to the product\n* is never complete\n* constantly changes\n* refinement\n    * design, decomposition, analysis\n    * items are reviewed and revised\n        * act of adding detail, estimates, and order to items\n    * Scrum Team collaborates on the details of Product Backlog item\n    * Scrum Team decides how and when refinement is done\n    * usually consumes no more than 10% of the capacity of the Development Team\n* items that can be \"Done\" within one Sprint are \"Ready\" for selection in a Sprint Planning\n* Development Team is responsible for all estimates\n* Monitoring Progress Toward Goals\n    * Product Owner tracks this total work remaining at least every Sprint Review\n    * burn-downs, burn-ups, or cumulative flows\n\n### Sprint Backlog\n* set of Product Backlog items selected for the Sprint\n    * plus a plan for delivering the product Increment and realizing the Sprint Goal\n    * makes visible all the work necessary to meet the Sprint Goal\n* includes at least one high priority process improvement from Retrospective\n    * remark: it has to be added to Spring Backlog not Product Backlog\n* only the Development Team can change it during a Sprint\n* Monitoring Sprint Progress\n    * at least every Daily Scrum to project the likelihood of achieving the Sprint Goal\n\n### Increment\n* sum of all items completed during a Sprint + value of the increments of all previous Sprints\n* meets the definition of \"Done\"\n* Increment is useable, so a Product Owner may choose to immediately release it\n    \n### Definition of \"Done\"\n* Development Team must define a definition of \"Done\"\n    * if not a convention of the development organization\n* everyone must understand what \"Done\" means\n* definitions of \"Done\" will expand to include more stringent criteria for higher quality\n* when many Development Teams are working on a single product all Development Teams \nmust have a definition of \"Done\" that makes their combined work potentially releasable\n* use to assess when work is complete on the product Increment\n* guides the Development Team in knowing how many Product Backlog items it can select during a Sprint Planning\n* ensures artifact transparency","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fmtumilowicz%2Fscrum-notes","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fmtumilowicz%2Fscrum-notes","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fmtumilowicz%2Fscrum-notes/lists"}