Scrum is an iterative and incremental Agile software development framework for managing software projects and product or application development. Its focus is on “a flexible, holistic product development strategy where a development team works as a unit to reach a common goal” as opposed to a “traditional, sequential approach”. Scrum enables the creation of self-organizing teams by encouraging co-location of all team members, and verbal communication among all team members and disciplines in the project.
A key principle of Scrum is its recognition that during a project the customers can change their minds about what they want and need (often called requirements churn), and that unpredicted challenges cannot be easily addressed in a traditional predictive or planned manner. As such, 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.
Why should you use Scrum?
Scrum has the power to transform project management across every industry, every business, and even across life in general. By using Scrum, you’ll become more Agile, discovering how to react more quickly and respond more accurately to the inevitable change that comes your way. And by staying focused, collaborating, and communicating, you can accomplish what truly needs to be done — successfully.
Most important, Scrum is not unproven hype. It’s a solid and successful Agile framework that’s been applied to a variety of projects and teams. Universities use Scrum to deliver valued projects to clients. Militaries have relied on Scrum to prepare ships for deployment. In the automotive world, Team Wikispeed is using Scrum to build a fast, affordable, ultra-efficient, safe commuter car that should sell for less than $20,000.
So whether you’re working on the next smartphone app, managing logistics for a store, or planning a charity event, you should take a closer look at using Scrum. And Scrum Alliance can give you the proven framework, best implementation practices, and supportive guidance you need to achieve success.
Courtesy :https://www.scrumalliance.org
Timebox
Scrum relies heavily on the concept of Timebox. Timebox is setting a fixed time limit to any activity and letting other characteristics such as Scope vary. A time box could be
- A Meeting
- A Sprint
- A Test activity
- Development Activity
- Or Practically anything such as you chatting with your friend on social networking site
The fact about timebox is that the time is limited. You can adjust other parameters such as
- How much you can get done
- Which item you must prioritize
- However, deadlines cannot be moved.
In Scrum, all the project iterations, meetings must be timeboxed and time limits be respected. This is very important and non-negotiable aspect of Scrum.
Lets look at how a timebox actually works.
- Timeboxcan be of any duration – hours, months, years
- It is essentially a control mechanism to ensure how much time you wish to devote to certain activity.
- Timeboxis done at lowest level so that we can achieve timeboxing at the right level
- If it so happens that the activity cannot be completed within the timebox available, the remaining items can be deferred to subsequent timebox. E.g. the way we plan the work in iterationis to limit the tie available and figure out how much functionality can be delivered within that timebox.
- Timeboxcan be used outside our project activity also to improve our personal productivity and time hygine. For e.g. A person may find that he/she is spending too much time on Social Media. One way to control this would be to limit how much time to spend on Social Media. i.e. limit the time say ½ hour a day. Initially you may feel very restrictive and you may feel that you are not able to achieve everything you wanted to achieve, but then, you will automatically focus on “What are the most important things to achieve” in the timebox. This focus will help you speed up, focus and complete all important things quickly at higher priority.
Sprint – Iterative and Incremental
A sprint is the basic unit of development in Scrum.
- The sprint is a “timeboxed” effort; that is, it is restricted to a specific duration. The duration is fixed in advance for each sprint and is normally between one week and one month, although two weeks is typical.
- Once agreed, the timelines of the Sprint“deadline” cannot be changed. The Sprint duration can be changed over the life of the project.
- Each sprint is started by a planning meeting, where the tasks for the sprint are identified and an estimated commitment for the sprint goal is made, and ended by a sprint review-and-retrospective meeting, where the progress is reviewed and lessons for the next sprint are identified.
- Scrumemphasizes working product at the end of the Sprint that is really “done”; in the case of software, this means a system that is integrated, fully tested, end-user documented, and potentially shippable.
Scrum break tasks into small increments with minimal planning and do not directly involve long-term planning. Sprints are short time frames (timeboxes) that typically last from two to four weeks. Each Sprint involves a cross-functional team working in all functions: planning, requirements analysis, design, coding, unit testing, and acceptance testing. At the end of the Sprint a working product is demonstrated to stakeholders. This minimizes overall risk and allows the project to adapt to changes quickly. An Sprint might not add enough functionality to warrant a market release, but the goal is to have an available release at the end of each iteration. Multiple iterations might be required to release a product or new features.
The Scrum Roles
The Product Owner
The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals. The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes:
- Clearly expressing Product Backlogitems;
- Ordering the items in the Product Backlogto best achieve goals and missions;
- Optimizing the value of the work the Development Teamperforms;
- Ensuring that the Product Backlogis visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
- Ensuring the Development Teamunderstands items in the Product Backlog to the level needed.
The Product Owner may do the above work, or have the Development Team do 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 organization must respect his or her decisions. The Product Owner’s 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.
The 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 value created by the Scrum Team.
The Development Team
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. Only members of the Development Team create the Increment.
Development Teams are structured and empowered by the organization to organize and manage their own work. The resulting synergy optimizes the Development Team’s overall efficiency and effectiveness.
Development Teams have the following characteristics:
- They are self-organizing. No one (not even the ScrumMaster) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;
- Development Teams are cross-functional, with all of the skills as a team necessary to create a product Increment;
- Scrumrecognizes no titles for Development Team members other than 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.
- The team should be cross functional. i.e. they should have all skills necessary to complete all work necessary to deliver value to customer.
The Scrum Artifacts
The Detailed set of artifacts in Agile Methodology includes all the Scrum Artifacts. The details of the same can be found in the chapter on “Agile Artifacts”. The intention of this chapter is to introduce the Scrum Artifacts so that you can relate and understand the Scrum Lifecycle better.
Product Backlog
The requirements in Scrum are called Backlog. Backlog is everything that is yet to be done and not necessarily the activities that the team has fallen behind.
The product backlog is an ordered list of requirements that is maintained for a product. It consists of features, bug fixes, non-functional requirements, etc.—whatever needs to be done in order to successfully deliver a viable product. The product backlog items (PBIs) are ordered by the Product Owner based on considerations like risk, business value, dependencies, date needed, etc.
The product backlog contains the Product Owner’s assessment of business value and the Development Team’s assessment of development effort.
The product backlog and the business value of each backlog item is the responsibility of the Product Owner.
The size (i.e. estimated complexity or effort) of each backlog item is, however, determined by the Development Team, who contributes by sizing items, either in story points or in estimated hours.
- The requirements in Agile are called Backlog. Backlog is everything that is yet to be done and not necessarily the activities that the team has fallen behind.
- The product backlogis an ordered list of requirements that is maintained for a product.
- It consists of features, bug fixes, non-functional requirements, etc.—whatever needs to be done in order to successfully deliver a viable product. The product backlog items (PBIs) are ordered by the Product Ownerbased on considerations like risk, business value, dependencies, date needed, etc.
- Items added to a backlog are commonly written in story format. The product backlogis what will be delivered, ordered into the sequence in which it should be delivered. It is open and editable by anyone, but the Product Owner is ultimately responsible for ordering the items on the backlog for the Development Team to choose.
- The product backlogcontains the Product Owner’s assessment of business value and the Development Team’s assessment of development effort, which are often, but not always, stated in story points. These estimates help the Product Owner to gauge the timeline and may influence ordering of backlog items.
- The product backlogand the business value of each backlog item is the responsibility of the Product Owner. The size (i.e. estimated complexity or effort) of each backlog item is, however, determined by the Development Team, who contributes by sizing items, either in story points or in estimated hours.
- Scrumadvocates that the role of Product Owner be assigned. The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. The Product Owner gathers input, takes feedback and is lobbied by many people, but it will ultimately make the call on what gets built. Product Owner is solely responsible for the management of the backlog.
- Ideally the Product owner needs to have clarity of all requirements that need to be taken up in the next 2 or 3 sprints. The rest of the stories could be kept at a fairly high level. The Backlog Grooming Sessions during the Sprints are used to get clarity on the backlog items which are not clear.
- A Backlog is a live document or list that the Product owner continuously updates
| Example
Let us look at a small list of items that could be part of a Product Backlog. Each item in the backlog is essentially a short description of a requirement to meet the need of the customer or add value to customer. Let us consider a ticket booking system project
The description is provided by the product Owner in consultation with the stakeholders. The size is expressed in some units and is provided by the team. The Size will be discussed in more detail when we discuss estimation. Backlog items could be · Functional Requirements (items 1,2 in the above table) · Non Functional Requirements (item 4 in the above table) · Bug Fixes (Item 3 in the above table) · Upgrades (Item 6,7 in the above table) |
In short any work that team could do for the customer should be routed thru the backlog.
Let us list down the different Backlogs
- Product Backlog
- Product Backlog may contain “Epics” and “User Stories”
- A sprint Backlog is a subset of Release Backlog and represents the items that team has agreed to implement within a given Sprint
- Sprint Backlog may further breakdown specific Stories into tasks (sometimes called Sub-Stories) that need to be accomplished
Sprint Backlog
The list of the tasks to be executed by the Scrum Team in upcoming Sprint is called the “Sprint Backlog”.
It is common practice that the Sprint Backlog is represented on a task board which provides a constantly visible depiction of the status of the user stories in the backlog. Also included in the Sprint Backlog are any risks associated with the various tasks. Any mitigating activities to address the identified risks would also be included as tasks in the sprint Backlog.
Once the Sprint Backlog is finalized and committed to by the Team, new User Stories should not be added. However, tasks that might have been missed or overlooked from the committed User Stories may need to be added. If new requirements arise during a Sprint, they will be added to the overall Prioritized Product Backlog and included in a future sprint.
The Sprint backlog is the list of work the Development Team must address during the next sprint. The list is derived by selecting product backlog items from the top of the product backlog until the Development Team feels it has enough work to fill the sprint. This is done by the Development Team asking “Can we also do this?” and adding product backlog items to the sprint backlog. The Development Team should keep in mind its past performance assessing its capacity for the new sprint, and use this as a guide line of how much “effort” they can complete.
Increment
The Increment is the sum of all 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 that it should be in a useable condition and meet the Scrum Team’s definition of Done. It must be in a useable condition regardless of whether the Product Owner decides to actually release it.
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.
Sprint planning meeting
At the beginning of the sprint cycle (every 7–30 days), a “Sprint planning meeting” is held.
- Select what work is to be done
- Prepare the SprintBacklog that details the time it will take to do that work, with the entire team
- Identify and communicate how much of the work is likely to be done during the current sprint
- Eight-hour time limit
o (1st four hours) Entire team: dialog for prioritizing the Product Backlog
o (2nd four hours) Development Team: hashing out a plan for the Sprint, resulting in the Sprint Backlog
Daily Scrum meeting
A Daily Scrum meeting in the computing room. This choice of location lets the team start on time.
Each day during the sprint, a project team communication meeting occurs. This is called a Daily Scrum (meeting) and has specific guidelines:
- All members of the development team come prepared with the updates for the meeting.
- The meeting starts precisely on time even if some development team members are missing.
- The meeting should happen at the same location and same time every day.
- The meeting length is set Timeboxed to 15 minutes.
- All are welcome, but normally only the core roles speak.
During the meeting, each team member answers three questions:
- What have you done since yesterday?
- What are you planning to do today?
- Any impediments/stumbling blocks? Any impediment/stumbling block identified in this meeting is documented by the ScrumMaster and worked towards resolution outside of this meeting. No detailed discussions shall happen in this meeting.
Sprint Review Meeting
At the end of a sprint cycle, two meetings are held: the “Sprint Review Meeting” and the “Sprint Retrospective”. This section describes the Sprint Review Meeting and next section describes the Sprint Retrospectives. One must understand that the objectives of both meetings are very different.
At the Sprint Review Meeting:
- Attended by Product Owner, ScrumMaster, team and other stakeholders as required
- The objective of this meeting is
o To review the work that was completed
o The planned work that was not completed
o If the team is on track
o Get Feedback
- Present the completed work to the stakeholders (“the demo”)
- Incomplete work cannot be demonstrated
- Four-hour time limit
- Feedback from participants are reviewed and recorded. The product owner should consider the feedback as potential backlog items
Sprint Retrospective
The Retrospective is the event in Agile which brings in the iterative, inspective and adaptive nature into picture. The team reflects upon the previous timebox with a view to learn some lessons, adjust the behavior or environment in order to improve their experience.
A Retrospective is a special meeting that takes place after each sprint, in which the team members gather to inspect and improve their methods and teamwork.
Since Retrospectives happen during the project, the lessons and improvements that result from them are applicable and relevant to upcoming work on the same project.
Advantages of Retrospectives include the following
- Improved Productivity : By applying lessons learned and reducing rework, the team can get more productivity work done.
- Improved Capability : Retrospectives provide a venue for spreading knowledge, so does the number of people who can perform tasks associated with the knowledge.
- Improved Quality : We can improve quality on our projects by finding the circumstances that led to defects and removing the causes.
- Improved Capacity : Retrospectives focus on finding process efficiency improvements, which can improve the team capacity to do work.