Scrum Managment in VSO Part I – Overview

Hello Friend,

These days, I am looking more into Scrum Methodology and I found it really exciting that makes job easy for entire development team. And hence I decided to share my understanding via this course about Scrum and its implementation in VSO 2013 which is divided in three parts. Hope you will find it interesting!

Let’s Start with Part I that explains about Scrum Methodology.

A Scrum is an iterative and incremental agile software development framework for managing project development work. Actually, Fundamental of Scrum is well known as SCRUMDAMENTALS.Let’s dig into it!

What is Scrum

A scrum is a process framework that has been used to manage complex product development since the early 1990s. Scrum is not a process or a technique for building Applications; rather, it is a framework within which a team member can employ various processes and techniques.

Scrum makes efficient project management and development practices which is useful to project team member to improve further. The Scrum framework consists of Scrum Teams and their associated roles, events, artifacts, and rules. Each component within the framework serves a specific purpose and is essential to Scrum’s success and usage. The rules of Scrum bind together the events, roles, and artifacts, governing the relationships and interaction between them which we will understand throughout this document.

Scrum methodology helps to reduce the challenges mentioned below so that team member can focus all energy on the most valuable area in a project:

• What features to develop?

• Deadline for changes?

• What to prioritize first?

Scrum is not the secret ingredient for success, but it does certainly help us to achieve better results on the development projects as follows:

1. Emphasis on communication: Scrum promotes communication between our project team members. It also promotes a good team work attitude.

2. Quick results: On average, a couple of iterations (sprints) are sufficient to show a working product. This way, we get early feedback which helps shape the work ahead.

3. Focus on what is important: Since all the items are prioritized based on their business value, no time is wasted developing what is not important.

4. Fair time estimates: Since the production team is involved in the estimating of the Product Backlog cards, the overall time estimate is fairly and square (accurate).

5. Self-organization: The project team is a self-organized unit that works to reach the Sprint Goal on time. A mix of skill sets and skill levels are often ideal to promote a continuous work flow.

6. Transparency: Scrum promotes transparency as everyone knows what is going to be delivered in the sprint, since work has been prioritized in the Product Backlog and visible to all team members.

Scrum Team and Responsibilities

The Scrum Team consists of:

1. Product Owner
2. Development Team
3. Scrum Master

Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team. The team model in Scrum is designed to optimize flexibility, creativity, and productivity.

Scrum Teams deliver products iteratively and incrementally, maximizing opportunities for feedback. Incremental deliveries of “Done” product ensure a potentially useful version of working product is always available. Scrum Teams always have the following characteristics:

• Team members share the same norms and rules.
• The Scrum team as a whole is accountable for the delivery.
• Team members in Scrum Team is collocated, empowered and self-organizing.
• It is working as autonomous as it is possible.
• The skills within the Scrum team are balanced.
• A Scrum Team is small and has no sub-teams.
• The people within the Scrum Team work full time with the team.

The Scrum Team and each of the team members has certain responsibilities which have to be fulfilled as explained follow:

1. Product Owner: The Product Owner is responsible for maximizing the value of the applications and the work of the Development Team. The Product Owner is the sole person responsible for managing the Product Backlog.

Product Backlog management includes:

• It’s a voice of the customer and defines the “What” of the product.
• Manages business value and Owns Product Backlog.
• Can change the priorities of the product backlog – but not after it has been taken into the sprint.
• Clearly expressing Product Backlog items.
• Optimizing the value of the work the Development Team performs.
• Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next.
• Ensuring the Development Team understands items in the Product Backlog to the level needed.

The Product Owner may do the above work, or have the Development Team done it. However, the Product Owner remains accountable. The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog

Item’s priority must address the Product Owner.

For the Product Owner to succeed, the entire project team must respect his or her decisions. The Product Owners’ decisions are visible in the content and ordering of the Product Backlog. No one is allowed to tell the Development Team to work from a different set of requirements, and the Development Team isn’t allowed to act on what anyone else says.

2. Development Team: The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” application at the end of each Sprint. Only members of the Development Team create the Increment.

Development Teams have the following characteristics:

• They are self-organizing. No one (not even the Scrum Master) tells the Development Team.
• They are responsible to turn Product Backlog into Increments of potentially replaceable functionality.
• Development Teams are cross-functional, with all of the skills as a team necessary to create application Increment.
• Scrum recognizes no titles for Development Team members other than the Developer regardless of the work being performed by the person; there are no exceptions to this rule.
• Scrum recognizes no sub-teams in the Development Team regardless of particular domains that need to be addressed like testing or business analysis; there are no exceptions to this rule.
• Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.

3. Scrum Master: The Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules. The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the

The value created by the Scrum Team.

The Scrum Master serves the Product Owner in several ways, including:

• Finding techniques for effective Product Backlog management.
• Helping the Scrum Team understand the need for clear and concise Product Backlog items.
• Understanding product planning in an empirical environment.
• Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value.
• Understanding and practicing agility.
• Facilitating Scrum events as requested or needed.

The Scrum Master Service to the Development Team as follows:

• Coaching the Development Team in self-organization and cross-functionality.
• Helping the Development Team to create high-value products.
• Removing impediments to the Development Team’s progress.
• Facilitating Scrum events as requested or needed.

The Scrum Master serves the organization in several ways, including:

• Leading and coaching the organization in its Scrum adoption.
• Planning scrum implementations within the organization.
• Helping employees and stakeholders understand and enact Scrum and empirical application development.
• Causing change that increases the productivity of the Scrum Team.
• Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization.

As a whole Scrum Team, they have to follow certain responsibilities as well:

• They have to break down the requirements, create tasks, estimate and distribute them. In other words, this means that they have to create the Sprint Backlog.
• They have to perform the short Daily Sprint Meeting.
• They have to ensure that at the end of the Sprint potentially shippable functionality is delivered.
• They have to update the status and the remaining efforts for their tasks to allow creation of a Sprint Burn down Diagram.

Scrum Artifacts

Scrum artifacts represent the work or value to provide transparency and opportunities for inspection and adaptation. Artifacts defined by Scrum are specifically designed to maximize transparency of key information so that everybody has the same understanding of the artifact.

1. Product Backlog: The Product Backlog is an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering. 

The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases. Product Backlog items have the attributes of a description, order, estimate and value.

The Development Team is responsible for all estimates. The Product Owner may influence the Development Team by helping it understand and select trade-offs, but the people who will perform the work make the final estimate.

2. Sprint Backlog: The 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 Sprint Backlog is a forecast by the Development Team about what functionality will be in the next Increment and the work needed to deliver that functionality into a “Done” Increment. The Sprint Backlog makes visible all of the work that the Development Team identifies as necessary to meet the Sprint Goal. 

As new work is required, the Development Team adds it to the Sprint Backlog. As work is performed or completed, the estimated remaining work is updated. When elements of the plan are deemed unnecessary, they are removed. Only the Development Team can change its Sprint Backlog during a Sprint. The Sprint Backlog is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint, and it belongs solely to the Development Team.

Difference between Product backlog and Sprint backlog:

In exceptional cases, when all items have been done before the end of the Sprint, the Development Team can pick the next item from the Product Backlog and start working on it for the remaining duration of the Sprint.

 So, as we can see on the image above, the main difference between product backlog and sprint backlog is that a list of features (wish list) is not the same as a time-boxed development cycle (to-do-list). Without the Product Backlog there are no tasks to be performed on a Sprint Backlog. Therefore the Sprint Backlog depends entirely on the Product Backlog to exist.

The following table details many of the key differences between product and sprint backlogs.

Item	Product Backlog	Sprint Backlog
Level of detail	Less detailed	Very detailed
Estimation units	Story Points	Hours
Document ownership	Product Owner	Team
Revised	Weekly	Daily
Duration	Project	Sprint
Workbook	Product Backlog workbook	Iteration Backlog workbook

3. Product Increment: Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints. At the end of a Sprint, the new Increment must be “Done,” which means it must be in usable condition and meet the Scrum Team’s definition of “Done.” It must be in useable condition regardless of whether the Product Owner decides to actually release it. the product increment should be complete enough to demonstrate its working functionality. A scrum project is complete after a product contains enough shippable functionality to meet the business goals for the project.

4. Burn down Chart: A Burn down report shows how much work remained at the end of specified intervals during a sprint. The source of the raw data is the sprint backlog. The horizontal axis shows days in a sprint, and the vertical axis measures the amount of work that remains to complete the tasks in the sprint. The work that remains is shown in hours. A burn down graph displays the following pieces of data:

• The Ideal Trend line indicates an ideal situation in which the team burns down all of the effort that remains at a constant rate by the end of the sprint.
• The In Progress series shows how many hours remain for tasks that are marked as In Progressin a sprint.
• The To Do series show how many hours remain for tasks that are marked as To Do in a sprint.

Both the In Progress and the To Do series are drawn based on the actual progress of your team as it completes tasks. The following illustration shows an example of a burn down graph. 

5. The definition of “Done”: When a Product Backlog item or an Increment is described as “Done”, everyone must understand what “Done” means. Although this varies significantly per Scrum Team, members must have a shared understanding of what it means to work to be complete, to ensure transparency. This is the definition of “Done” for the Scrum Team and is used to assess when work is complete on the product Increment.

The same definition guides the Development Team in knowing how many Product Backlog items it can select during a Sprint Planning. The purpose of each Sprint is to deliver Increments of potentially reusable functionality that adhere to the Scrum Team’s current definition of “Done.” Development Teams deliver an Increment of product functionality every Sprint. This Increment is useable, so a Product Owner may choose to immediately release it. If the definition of “done” for an increment is part of the conventions, standards or guidelines of the development organization, all Scrum Teams must follow it as a minimum. If “done” for an increment is not a convention of the development organization, the Development Team of the Scrum Team must define a definition of “done” appropriate for the product. If there are multiple Scrum Teams working on the system or product release, the development teams in all of the Scrum Teams must mutually define the definition of “Done.”

Each Increment is additive to all prior Increments and thoroughly tested, ensuring that all Increments work together.

As Scrum Teams mature, it is expected that their definitions of “Done” will expand to include more stringent criteria for high quality. Any one product or system should have a definition of “Done” that is a standard for any work done on it.

In short, Definition of Done is as follow:

• Agreed between the Product Owner and the Team.
• Same across the enterprise.
• Start small and grow.
• Not done items not demonstrated in the review
• Critical for the Team to keep this insight. 

And, what is done? :

• Designed.
• Developed.
• Code Analysis.
• Coded Reviewed.
• Refactored.
• Unit Tested.
• Documented
• User Acceptance.

Scrum Events

Prescribed events are used in Scrum to create regularity and to minimize the need for meetings not defined in Scrum. All events are time-boxed events, such that every event has a maximum duration. Once a Sprint begins, its duration is fixed and cannot be shortened or lengthened. The remaining events may end whenever the purpose of the event is achieved, ensuring an appropriate amount of time is spent without allowing waste in the process.

Other than the Sprint itself, which is a container for all other events, each event in Scrum is a formal opportunity to inspect and adapt something. These events are specifically designed to enable critical transparency and inspection. Failure to include any of these events results in reduced transparency and is a lost opportunity to inspect and adapt.

The Sprint:

The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created. Sprints best have consistent durations throughout a development effort. A new Sprint starts immediately after the conclusion of the previous Sprint.

Sprints contain and consist of the Sprint Planning, Daily Scrums, the development work, the Sprint Review, and the Sprint Retrospective.

During the Sprint:

• No changes are made that would endanger the Sprint Goal.
• Quality goals do not decrease.
• The 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 a one-month horizon. Like projects, Sprints are used to accomplish something. Each Sprint has a definition of what is to be built, a design and flexible plan that will guide, building it, the work, and the resultant product.

Sprints are limited to one calendar month. When a Sprint’s horizon is too long the definition of what is being built may change, complexity may arise, and risk may increase. Sprints enable predictability by ensuring inspection and adaptation of progress toward a Sprint Goal at least every calendar month. Sprints also limit risk to one calendar month of cost.

The 2-4 weeks sprint cycle can be visualized with this diagram.

 Sprint Planning Meeting: The work to be performed in the Sprint plans at the Sprint Planning. This plan is created by the collaborative work of the entire Scrum Team.

Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter. The Scrum Master ensures that the event takes place and that attendants understand its purpose. The Scrum Master teaches the Scrum Team to keep it within the time-box.

Sprint Planning answers the following:

• What can be delivered in the Increment resulting from the upcoming Sprint?
• How will the work needed to deliver the Increment be achieved?

The Development Team works to forecast the functionality that will be developed during the Sprint. The Product Owner discusses the objective that the Sprint should achieve and the Product Backlog items that, if completed in the Sprint, would achieve the Sprint Goal. The entire Scrum Team collaborates on understanding the work of the Sprint.

The input to this meeting is the Product Backlog, the latest product Increment, projected capacity of the Development Team during the Sprint, and past performance of the Development Team. The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team. Only the Development Team can assess what it can accomplish over the upcoming Sprint.

By the end of the Sprint Planning, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment.

Daily Scrum Meeting: The Daily Scrum is a 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours. This is done by inspecting the work since the last Daily Scrum and forecasting the work that could be done before the next one. The Daily Scrum is held at the same time and place each day to reduce complexity. During the meeting, the Development Team members explain:

• What did I do yesterday that helped the Development Team meet the Sprint Goal?
• What will I do today to help the Development Team meet the Sprint Goal?
• Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

The Development Team uses the Daily Scrum to inspect progress toward the Sprint Goal and to inspect how progress is trending toward completing the work in the Sprint Backlog. The Daily Scrum optimizes the probability that the Development Team will meet the Sprint Goal. Every day, the Development Team should understand how it intends to work together as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment by the end of the Sprint. The Development Team or team members often meet immediately after the Daily Scrum for detailed discussions, or to adapt, or replan, the rest of the Sprint’s work.

The Scrum Master ensures that the Development Team has the meeting, but the Development Team is responsible for conducting the Daily Scrum. The Scrum Master teaches the Development Team to keep the Daily Scrum within the 15-minute time-box.

The Scrum Master enforces the rule that only Development Team members participate in the Daily Scrum.

Daily Scrums improve communications, eliminate other meetings, identify impediments to development for removal, highlight and promote quick decision-making, and improve the Development Team’s level of knowledge. This is a key, inspect and adapt meeting.

Sprint Review Meeting:

A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value. This is an informal meeting, not a status meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration.

This is a four-hour time-boxed meeting for one-month Sprints. For shorter Sprints, the event is usually shorter. The Scrum Master ensures that the event takes place and that attendants understand its purpose. The Scrum Master teaches all to keep it within the time-box.

The Sprint Review includes the following elements:

• Attendees include the Scrum Team and key stakeholders invited by the Product Owner;
• The Product Owner explains what Product Backlog items have been “Done” and what has not been “Done”;
• The Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved;
• The Development Team demonstrates the work that it has “Done” and answers questions about the Increment;
• The Product Owner discusses the Product Backlog as it stands. He or she projects likely completion dates based on progress to date (if needed);
• The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning;
• A review of how the marketplace or potential use of the product might have changed what is the most valuable thing to do next; and,
• Review of the timeline, budget, potential capabilities, and marketplace for the next anticipated release of the product.

The result of the Sprint Review is a revised Product Backlog that defines the probable Product Backlog items for the next Sprint. The Product Backlog may also be adjusted overall to meet new opportunities.

Sprint Retrospective: The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.

The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning. This is a three-hour time-boxed meeting for one-month Sprints. For shorter Sprints, the event is usually shorter. The Scrum Master ensures that the event takes place and that attendants understand its purpose. The Scrum Master teaches all to keep it within the time-box. The Scrum Master participates as a peer team member in the meeting from the accountability over the Scrum process.

The purpose of the Sprint Retrospective is to:

• Inspect how the last Sprint went with regards to people, relationships, process, and tools;
• Identify and order the major items that went well and potential improvements; and,
• Create a plan for implementing improvements to the way the Scrum Team does its work.

The Scrum Master encourages the Scrum Team to improve, within the Scrum process framework, its development process and practices make it more effective and enjoyable for the next Sprint. During each Sprint Retrospective, the Scrum Team plans ways to increase product quality by adapting the definition of “Done” as appropriate.

By the end of the Sprint Retrospective, the Scrum Team should have identified improvements that it will implement in the next Sprint. Implementing these improvements in the next Sprint is the adaptation to the inspection of the Scrum Team itself. Although improvements may be implemented at any time, the Sprint Retrospective provides a formal opportunity to focus on inspection and adaptation.

In this post, we have understood the over all view of the scrum methodology , now its turn to implement this in real time and here its posted as next part of this series !

Happy Scrumming ! 🙂