Scrum - projeto-coruja/Projeto-Coruja GitHub Wiki

Scrum is a framework within which people can address complex adaptive problems, it is lightweight, simple to understand and extremely difficult to master. And you can also employ various processes and techniques, it makes clear the relative efficacy of your product management and development practices so that you can improve.

Scrum Theory Scrum is founded on empirical process control theory, it asserts that knowledge comes from experience and making decisions based on what is known. Scrum employs an iterative, incremental approach to optimize predictability and control risk. Three pillars uphold every implementation of empirical control: transparency, inspection and adaptation.

Transparency: significant aspects of the process must been visible responsible for the results. Transparency requires common standard aspects, so observers hare a common understanding of what is being seen.

Inspection: scrum user must frequently insect Scrum artifacts and progress toward a goal to detect undesirable variances.

Adaptation: if a one or more aspects deviate outside acceptable limits, and that the resulting product will be unacceptable, the process on the material being processed mus be adjusted, and it needs to be made as soon as possible.

Four formal opportunities for inspection and adaptation: Sprint Planning Meeting, Daily Scrum, Sprint Review and Sprint Retrospective.

Scrum consists of Scrum team and their associated roles, events, artifacts and rules; each of them serves a specific purpose and is essential to Scrum's success and usage.

The Scrum Team: Product Owner, the development team and the Scrum Master. The Scrum team are self-organizing and cross-functional, they choose how best to accomplish their work and have all competencies needed to accomplish without depending on others not part of the team. The team model is Scrum is designed to optimize flexibility, creativity and productivity. Scrum Teams deliver products iteratively and incrementally, maximizing opportunities to feedback.

The product owner: is responsible for maximizing the value of the product and the work of the Development team. He is the sole person responsible for managing the Product Backlog, and it includes: clearly expressing Product Backlog items; ordering the items in the product to best achieve goals and missions; ensuring the value of the work of the development team; ensuring that the product backlog is visible, transparent and clear to all and ensuring the development team understands items in the product backlog to the level needed. For the product Owner to succeed, the entire organization must respect his or her decisions, his/her decisions are visible in the content and ordering of the product backlog. No one is allowed to change the requirements, and the development team isn't allowed to act what anyone else says.

The Development Team: consists of professionals who do the work of delivering a potentially releasable Increment of “done” product at the end of each Sprint. Development Teams are structured and empowered bay the organization to organize and manage their own work. Some characteristics: -they are self-organizing, cross-functional, the accountability belongs to the Development Team as a whole and the they don't contain sub-teams dedicated to particular domains like testing or business analysis. -Optimal Development Team size is small enough to remain nimble and large enough to complete significant work.

The Scrum Master: is responsible for ensuring Scrum is understood and enacted, he/she does this by ensuring that the Scrum team adheres to Scrum theory, practices and rules.

Scrum Events: are used to create regularity, Scrum uses time-boxed events, such that every event has maximum duration, this ensures an appropriate amount of time is spent. This events are designed to enable critical transparency and inspection.

The Sprint: the heart of Scrum, a time-box of one month or less during which a “done”, usable, and potentially releasable product Increment is created. Sprints contain and consist of the Sprint Meeting, Daily Scrums, the development work, the Sprint Review and the Sprint Retrospective. During the sprint: no changes are made that would affect the Sprint Goal; Development team composition remains constant; quality goals do not decrease and scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned. Each Sprint may be considered a project with no more than one-month horizon, like projects Sprints are used to accomplish something, each of them has a definition of what is to built, a design and flexible plan that guide building it, the work and resultant product. Only the Product Owner has the authority to cancel the Sprint, when it occurs any completed and “done” product backlog are reviewed, if part of the work is potentially releasable the Product Owner may accept it. Sprint cancellation consume resources, since another Planning Meeting is necessary to start another Sprint.

Sprint Planning Meeting: at this meeting the Sprint plan is created by the entire Scrum Team, this meeting consists of two parts that answer the questions respectively: -What will be delivered int the Increment resulting from the upcoming Sprint? - which functionality will be developed during the Sprint. -How will the work needed to delivered the Increment be achieved? - the Development Team decides w it will build this functionality into a “done” product Increment during the Sprint.

Sprint Goal: gives the Development Team some flexibility regarding the functionality implemented with the Sprint, the Sprint goal may be a milestone in the larger purpose of the product roadmap.

Daily Scrum: is 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours. The developers use the Daily Scrum to assess progress toward the Sprint Goal and assess how progress is trending toward completing the work in the Sprint Backlog.

Sprint Review: is held at the end of the Sprint to inspect the Incremental and adapt the Product Backlog if needed, in the review is product owner identifies what has been “done” and what hasn't been “done”; the developers discuss what went and what didn't and how to solve the faced problems., they also demonstrated the work “done” and answer some questions and the entire group collaborates on what to do next.

Sprint Retrospective: an opportunity for the Scrum Team to inspect and create a plan for improvements to be enacted during the next Sprint. It occurs after the Sprint review and before the next Sprint Planning. The purpose of this retrospective is to:

-inspect how the last Sprint went on relationships, process ad tools;
-identify and order the major item that went well and potential improvements;
-and create a plan for implementing improvements to the way the Scrum does its work.

Scrum Artifacts represent work or value in various ways that are useful in providing transparency and opportunities to inspection and adaptation, the artifacts defined by Scrum are specifically designed to maximizing transparency of key information needed to ensure Scrum teams are successful in delivering a “done” increment.

Product Backlog: is an ordered list of everything that might be needed in the product is the single source of requirements for any changes to be made to the product. The Product Backlog evolves as the product and the environment in which it will used evolves, it is dynamic with constant changes. The Product backlog list all features, functions, requirements, enhancements and fixes thats constitute the changes to be made to the product int features releases, and it is often ordered by value, risk, priority and necessity. Requirements never stop changing, so a Product Backlog is a living artifact. Many estimates are made on the product backlog, he developers are responsible for all estimates the Product Owner may influence but the people who will perform the work make the final estimate.

Sprint Backlog: is the set of Product Backlog items selected for the Sprint plus a plan for delivering the product Increment and realizing the Sprint Goal. The Backlog makes visible all of the work that the developers identifies as necessary to meet the Sprint Goal.

Increment: is the sum of all the Product Backlog items completed during a Sprint and all previous Sprint. At the end of a Sprint, the new increment must be “done”, which means it must be usable condition ad meet the Scrum Team's Definition of “done”.

Definition of “Done”: everyone must understand what “done means”. The purpose of each Sprint is to deliver Increments of potentially releasable functionality that adhere to the Scrum Team's current Definition of “Done”. Each Increment is additive to all prior Increments to thoroughly tested, ensuring that all increments work together. As a Scrum Team mature is expected that the definition of “done ” will expend to include more stringent criteria for higher quality.

Conclusion: Scrum's roles, artifacts, events and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies and practices.