The document provides an overview of Agile Project Management using the Scrum methodology. It discusses the history and origins of Scrum, defines key Scrum roles like the Product Owner, Scrum Master, and Team. It also explains Scrum concepts like the Product Backlog, Sprints, Sprint Planning, Daily Scrums and more. The overall document aims to explain the basic principles and framework of managing projects using the Scrum Agile methodology.

1. Agile Project Management using Scrum Methodology Ajay Singh Rawat Vice-President Kronos Solutions India P. Ltd. Noida. [email_address]

2. What is the problem? Requirements not clear Frequent code changes Bug find-fix syndrome Scope creep Stabilization takes too long Releases take too long Changes are hard to make Quality is falling Unpredictable time lines Cost schedule over-run Customer dis-satisfaction Loss of morale and motivation Loss of reputation and market

3. History

4. Origin The rules of the game in new product development are changing. Many companies have discovered that it takes more than the accepted basics of high quality, low cost, and differentiation to excel in today’s competitive market. It also takes speed and flexibility. This new emphasis on speed and flexibility calls for a different approach for managing new product development. The traditional sequential or “relay race” approach to product development may conflict with the goals of maximum speed and flexibility. Instead, a holistic or “rugby” approach – where a team tries to go the distance as a unit, passing the ball back and forth – may better serve today’s competetive requirement. - Takeuchi, Hirotaka and Nonaka, Ikujiro. January-February 1986. “The New New Product Development Game.” Harvard Business Review.

5. Evolution THE ORIGINS OF SCRUM, OOPSLA 1996 The Scrum software development process uses an iterative, incremental approach. Interaction with the environment (technical, competitive, and user) is allowed, which will change the project scope, technology, functionality, cost, and schedule whenever required. Controls are used to measure and manage the impact. Scrum accepts that the development process is unpredictable. The product is the best possible software, factoring in cost, functionality, timing, and quality. - Schwaber, Ken. “Controlled Chaos: Living on the Edge.” American Programmer, April 1996.

6. Agile Manifesto We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more.

7. Scrum is Simple The rules and practices for Scrum—a simple process for managing complex projects—are few, straightforward, and easy to learn. But, Scrum’s simplicity itself—its lack of prescription—can be disarming. Scrum provides a simple framework of basic tenets to solve complex problems and drive better results—delivering more valuable software faster . Scrum is hard. It’s not hard because of the things you do; it’s hard because of the things you don’t do. There are no Gantt charts in Scrum, there’s no time reporting, and you don’t assign tasks to programmers. Instead you’ll learn the few simple rules of Scrum and how to use its frequent inspect-and-adapt cycles to create more valuable software faster.

8. Essence of Scrum The essence of Scrum is: The team makes a commitment to achieve a goals The team organizes itself for meeting its commitment The team delivers at regular interval the most valuable features The team strives to improve upon itself based on retrospective and feedback The team’s performance is always visible in terms of progress being made The team and management honestly communicate about progress and risks This way of working is based upon values of commitment, team spirit, self-respect, respect for others, trust and courage. Scrum does not instruct teams how to do their work but expects teams to do whatever necessary to fulfill the commitment and deliver the desired product.

9. The Scrum Team The Scrum Team consists of the Scrum Master, the Product Owner, and the Team. Scrum Team members are called “pigs.” Everyone else is a “chicken.” Chickens cannot tell “pigs” how to do their work. Chickens and pigs come from the story – “ A chicken and a pig are together when the chicken says, “ Let’s start a restaurant!” The pig thinks it over and says, “ What would we call this restaurant?” The chicken says, “Ham n’ Eggs!” The pig says, “ No thanks, I’d be committed, but you’d only be involved!”

10. Product Owner PO is responsible for representing the interests of everyone with a stake in the project. PO creates the project’s initial overall requirements, return on investment (ROI) objectives, and release plans. The list of requirements is called the Product Backlog. PO is responsible for using the Product Backlog to ensure that the most valuable functionality is produced first and built upon; The responsibilities of the Product Owner role are: Working on a shared vision Gathering requirements Managing and prioritising the Product Backlog Accepting the software at the end of each iteration Managing the release plan The profitability of the project (ROI)

11. The Team The Team is responsible for developing functionality and collectively responsible for the success of each iteration and of the project as a whole. Teams are self-managing, self-organizing, and cross-functional, and they are responsible for figuring out how to turn Product Backlog into an increment of functionality within an iteration and managing their own work to do so. The responsibilities of the Team or Team Member role are: Estimating size of backlog items Committing to increments of deliverable software - and delivering it Tracking own progress Self-managed but accountable to the Product Owner for delivering as promised

12. Scrum Master The Scrum Master is responsible for the Scrum process, for teaching Scrum to everyone involved in the project, for implementing Scrum so that it fits within an organization’s culture and still delivers the expected benefits, and for ensuring that everyone follows Scrum rules and practices. The responsibilities of the Scrum Master role are: Empowering and shepherding the team Removing impediments Keeping the process moving Institutionalize Scrum to the larger organization The Scrum Master is a friend, philosopher and guide for the team !

13. Product Backlog A Scrum project starts with a vision of the system to be developed which might be vague at first but it will become clearer as the project moves forward. PO is responsible for delivering the vision in a manner that maximizes the ROI, formulates a plan and converts that into a Product Backlog. Product Backlog is a list of requirements that will deliver the vision. Product Backlog is prioritized so that the items most likely to generate value are top priority. The prioritized Product Backlog is a starting point and is grouped into releases. Changes in the Product Backlog reflect changing business requirements and how quickly or slowly the Team can transform Product Backlog into functionality.

14. Sprint Planning All work is done in Sprints. Each Sprint is an iteration of 2 to 4 consecutive weeks. Each Sprint is initiated with a Sprint planning meeting, where PO and Team get together to collaborate about what will be done for the next Sprint. Selecting from the highest priority Product Backlog, the PO tells the Team what is desired, and the Team tells the Product Owner how much of what is desired it believes it can turn into functionality over the next Sprint. Sprint planning meetings cannot last very long — that is, they are time-boxed to avoid too much hand-wringing about what is possible. The goal is to get to work, not to think about working.

15. Sprint Backlog The Sprint planning has two parts - in first part PO presents the Product Backlog to the Team. The Team questions about the content, purpose, meaning, and intentions of the Product Backlog. Team selects as much Product Backlog as it believes it can turn into a completed increment of potentially shippable product functionality by the end of the Sprint. The Team commits to the PO that it will do its best. During the second part of the Sprint planning meeting, the Team plans out the Sprint. Because the Team is responsible for managing its own work, it needs a tentative plan to start the Sprint. The tasks that compose this plan are placed in a Sprint Backlog; the tasks in the Sprint Backlog emerge as the Sprint evolves. With Sprint planning meeting, the Sprint starts, and the clock is ticking toward the Sprint time-box.

16. The Sprint Sprint is time-boxed to the amount of time required to build something of significant interest to the PO and potentially shippable. The Team commits to Product Backlog during the Sprint planning meeting and Product Backlog is frozen until the end of the Sprint. The Team can seek outside advice, help, information, and support during the Sprint but no one can interfere during the Sprint. If the Sprint proves to be not viable, the Scrum Master can terminate the Sprint and initiate the next Sprint. If the Team feels itself unable to complete all of the committed Product Backlog during the Sprint, it can consult PO on which items to remove from the current Sprint. Conversely, it can consult PO on which additional Product Backlog items can be added to the Sprint. The Team members have two administrative responsibilities during the Sprint: attend the Daily Scrum meeting, and keep the Sprint Backlog up-to-date

17. Picture courtesy methodsandtools.com The Sprint

18. Daily Scrum Best held first thing in the day so that the Team members think of what they did the day before and what they plan to do today. All Team members are required to attend, if not possible in person, by telephone or by another Team member reporting on his status. The Scrum Master begins the meeting and proceeding around the room until everyone has reported. Each Team member should respond to three questions only: What have you done since the last Daily Scrum regarding this project? What will you do between now and the next Daily Scrum meeting regarding this project? What impedes you from performing your work as effectively as possible? The Scrum Master is responsible for moving the reporting along briskly, from person to person. Chickens are not allowed to talk and stand on the periphery of the Team so as not to interfere with the meeting.

19. Task Board Picture courtesy mountaingoatsoftware.com

20. Sprint Review Meeting At the end of the Sprint, a Sprint review meeting is held. The purpose of the Sprint review is for the Team to present to PO and stakeholders functionality that is done or is potentially shippable. Functionality not “done” cannot be presented. Artifacts cannot be shown as work products, and their use must be minimized. Sprint review starts with presenting the Sprint goal, the Product Backlog committed to and completed. At the end of the presentations, the stakeholders are polled to get their impressions, any desired changes, and the priority of changes. PO discusses with the stakeholders and the Team potential rearrangement of the Product Backlog based on the feedback. Stakeholders are free to voice comments or criticisms, identify functionality not delivered, identify any new functionality and request additions to the Product Backlog for prioritization.

21. Sprint Retrospective Meeting After Sprint review and prior to next Sprint planning, Scrum Master holds a Sprint retrospective meeting with the Team. The Sprint retrospective meeting is time-boxed and attended only by the Team, Scrum Master. PO is optional. At this time-boxed meeting, Scrum Master encourages Team to review, within the Scrum process framework and practices, its development process to make it more effective and enjoyable for the next Sprint. Team members answer two questions: What went well during the last Sprint? What could be improved in the next Sprint? The Scrum Master records the Team’s answers in summary form. The Scrum Master is not to provide answers but to facilitate the Team’s search for better ways for the Scrum process to work for it.

22. Sprint Burndown The trend of work remaining across time in a Sprint, a release, or a product. The source of the raw data is the Sprint Backlog and the Product Backlog, with work remaining tracked on the vertical axis and the time periods (days of a Sprint or Sprints) tracked on the horizontal axis. The Burndown report remaining estimated workload over the course of the project. Workload at the start of each Sprint is measured by summing all open Product Backlog work estimates. From Sprint to Sprint, the increase or decrease in these sums can be used to assess progress toward completing all work for a release by an expected date.

23. Product / Release Burndown The product burndown chart, also known as release burndown chart, measures the rate of delivery of a stream of running, tested, features over time. This rate is know as the team’s velocity. Because features vary in complexity, and therefore effort and time, we use a scale to compare their size. The most common scale is known as story points. Once a team has worked together for a few sprints, it generally establishes its velocity within a definable range. PO then use this velocity to predict the rate at which the team will deliver features in the future, leading to credible release plans.

24. New Trends Scrum continues to get refined with finer details getting identified and defined for improvements. Ever larger teams are adopting Scrum du to inherent benefits of faster and better development Geographically distributed teams and distributed scrum is becoming norm in large organizations with Scrum of Scrum being practiced. Evolution or search for newer methods continues and continuously new practices from across the industries are getting introduced into Scrum also. Kanban and Lean from manufacturing industry are two such examples. The search for excellence and perfection will continue and new developments will remain the norm rather than exceptions in this field.

25. References Nonaka, Ikujiro and Takeuchi, Hirotaka (1986). The New, New Product Development Game . Harvard Business Review, Jan-Feb 1986. Schwaber, Ken. Controlled Chaos: Living on the Edge. American Programmer. April 1996. Ken Schwaber and Mike Beedle. Agile Software Development with Scrum , (Prentice Hall, 2001) Schwaber, Ken (2007). The Enterprise and Scrum . Microsoft Press. Cockburn, Alistair (2007). Agile Software Development: The Cooperative Game (2nd edition) . Addison Wesley Cohn, Mike (2004). User Stories Applied . Addison Wesley. Cohn, Mike (2006). Agile Estimating and Planning . Prentice Hall. Sliger, Michele and Broderick, Stacia (2008). The Software Project Manager’s Bridge to Agility . Addison Wesley. Schwaber, Ken (2009). Scrum Guide . http://www.scrumalliance.com/resources Yip, Jason (2006). It's Not Just Standing Up: Patterns of Daily Stand-up Meetings . http://martinfowler.com/articles/itsNotJustStandingUp.html.

26. Thanks ! You can also reach me at [email_address]