SCRUM Theory

Scrum Theory

Scrum is founded on empirical process control theory, or empiricism. Empiricism 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 process control: transparency, inspection, and adaptation.

Transparency Significant aspects of the process must be visible to those responsible for the outcome. Transparency requires those aspects be defined by a common standard so observers share a common understanding of what is being seen.
For example:

• A common language referring to the process must be shared by all participants; and,
• A common definition of "Done"

1 must be shared by those performing the work and those accepting the work product. Inspection
Scrum users must frequently inspect Scrum artifacts and progress toward a goal to detect undesirable variances. Their inspection should not be so frequent that inspection gets in the way of the work. Inspections are most beneficial when diligently performed by skilled inspectors at the point of work.
Adaptation
If an inspector determines that one or more aspects of a process deviate outside acceptable limits, and that the resulting product will be unacceptable, the process or the material being processed must be adjusted. An adjustment must be made as soon as possible to minimize further deviation.

Scrum prescribes four formal opportunities for inspection and adaptation, as described in the Scrum Events section of this document.

• Sprint Planning Meeting
• Daily Scrum
• Sprint Review
• Sprint Retrospective

(Courtsey - 1991-2013 Ken Schwaber and Jeff Sutherland - Scrum.org)

Handling Projects with SCRUM-BAN

SCRUM-BAN

Scrum-ban is a software production model based on Scrum and Kanban. Scrum-ban is especially suited for maintenance projects or (system) projects with frequent and unexpected user stories or programming errors. In such cases the time-limited sprints of the Scrum model are of no appreciable use, but Scrum’s daily meetings and other practices can be applied, depending on the team and the situation at hand. Visualization of the work stages and limitations for simultaneous unfinished user stories and defects are familiar from the Kanban model. Using these methods, the team’s workflow is directed in a way that allows for minimum completion time for each user story or programming error, and on the other hand ensures each team member is constantly employed.

To illustrate each stage of work, teams working in the same space often use post-it notes or a large whiteboard. In the case of decentralized teams, stage-illustration such as Assembla, ScrumWorks, Rational Team Concert or JIRA in combination with GreenHopper can be used to visualize each team’s user stories, defects and tasks divided into separate phases.
In their simplest, the tasks or usage stories are categorized into the work stages

• Unstarted
• Ongoing
• Completed

If desired, though, the teams can add more stages of work (such as “defined”, “designed”, “tested” or “delivered”). These additional phases can be of assistance if a certain part of the work becomes a bottleneck and the limiting values of the unfinished work cannot be raised. A more specific task division also makes it possible for employees to specialize in a certain phase of work.

There are no set limiting values for unfinished work. Instead, each team has to define them individually by trial and error; a value too small results in workers standing idle for lack of work, whereas values too high tend to accumulate large amounts of unfinished work, which in turn hinders completion times.A rule of thumb worth bearing in mind is that no team member should have more than two simultaneous selected tasks, and that on the other hand not all team members should have two tasks simultaneously.

The major differences between Scrum and Kanban are derived from the fact that, in Scrum, work is divided into sprints that last a certain amount of time, whereas in Kanban the workflow is continuous. This is visible in work stage tables, which in Scrum are emptied after each sprint. In Kanban all tasks are marked on the same table. Scrum focuses on teams with multifaceted know-how, whereas Kanban makes specialized, functional teams possible.

Since Scrum-ban is such a new development model, there is not much reference material. Kanban, on the other hand, has been applied by Microsoft and Corbis.

^{(Courtsey Wikipedia)}

The Pig & Chicken Roles

"Pig" roles

The Pigs are the ones committed to the project in the Scrum process - they are the ones with "their bacon on the line."

§  Product Owner - Represents the voice of the customer. He/she ensures that the Scrum Team works with the "right things" from a business perspective. The Product Owner writes user stories, prioritizes them and then places them in the product backlog.

§  ScrumMaster - Scrum is facilitated by a ScrumMaster, whose primary job is to remove impediments to the ability of the team to deliver the sprint goal. The ScrumMaster is not the leader of the team (as the team is self-organizing) but acts as a buffer between the team and any distracting influences. The ScrumMaster ensures that the Scrum process is used as intended. The ScrumMaster is the enforcer of rules. A key part of the ScrumMaster's role is to protect the team and keep them focused on the tasks in hand.

§  Team - Have the responsibility to deliver the product. A team is typically made up of 5–9 people with cross-functional skills who do the actual work (designer, developer, tester, technical communicator, etc.).

"Chicken" roles

Chicken roles are not part of the actual Scrum process, but must be taken into account. An important aspect of an Agile approach is the practice of involving users, internal business groups and stakeholders into portions of the process. It is important for these people to be engaged in the outcome of the project by providing feedback into the development, its review and planning for each sprint.

§  Users - The software is being built for the someone. "If software is not used"—much like "the tree falling in a forest" riddle—"was it ever written?"

§  Stakeholders - (customers, vendors) - These are the people who enable the project and for whom the project will produce the agreed-upon benefit[s], which justify its production. They are only directly involved in the process during the sprint reviews.

§  Managers - People who will set up the environment for the product development organizations.

{From Wikipedia, the free encyclopedia}

The Chicken and Pig Story

SCRUM Roles

The Scrum Team consists of the ScrumMaster, the Product Owner, and the Team. Scrum Team members are called “pigs”. The Product Owner is the “pig” of the Product Backlog. The Team is the “pig” of the Sprint work. The ScrumMaster is the “pig” of the Scrum process. Everyone else is a “chicken.” Chickens cannot tell “pigs” how to do their work.

A chicken and a pig are together when the chicken says, "Let's start a Project!"

The pig thinks it over and says, "What would we call this Project?"

The chicken says, “Agent Efficacy!"

The pig says, "No thanks, I'd be committed, but you'd only be involved!"

SCRUM " The Framework"

SCRUM Framework

SCRUM Framework Rules

SCRUM " The Process"

SCRUM "The Process"

"Out of the box". Most projects have a list of requirements, Scrum records requirements in a Product Backlog. Requirements need not be detailed nor do they need to be described fully. As with most projects, the requirements are sourced from the expected users or "the business". The Product Owner prioritizes the Product Backlog: items of importance to the project/business, i.e. those items that add immediate and significant business value, are bubbled up to the top.

The Project Team responsible for doing the actual work then creates a Sprint Backlog: this comprises of Product Backlog items that they believe can be completed within a 15 day period. The Project Team may liaise with the Product Owner and others in order to expand item(s) on the Sprint Backlog. After 15 days have elapsed, the team should have a "potentially shippable product increment". I will discuss the make-up of the Project Team later in this article, under the topic: Scrum Roles.

The Product Owner, the ScrumMaster and the Project Team will make an initial pass over the Product Backlog items where they work out roughly how long each item will take. Initially, these are estimates, best guesses. As time progresses, well within 15 days, we’ll know if the estimate was even close.

Scrum lets us refine our estimates on-the-fly: if we believe that a task will take longer than imagined, we have the ability to say so before the tasks starts. By only ever working with small work packages (time-boxed to 15 days), any schedule/requirement issues are dealt with as soon as they are identified, not much further downstream where the cost of recovery is considerably higher.

What does this "potentially shippable product increment" actually mean? Put simply, every 15 days, the team should provide something of value to the business, something they can use or something that provides considerable direction.