View stunning SlideShares in full-screen with the new iOS app!Introducing SlideShare for AndroidExplore all your favorite topics in the SlideShare appGet the SlideShare app to Save for Later — even offline
View stunning SlideShares in full-screen with the new Android app!View stunning SlideShares in full-screen with the new iOS app!
An Introductionto Agile Scrum By Sourav Mukherjee 6th Dec 2012
Expectations from this session What is scrum How can we use it in our projects Scrum benefits Scrum roles Scrum artifacts Scrum Daily Stand-up Scrum Planning Scrum Review & Retrospective Q&A
My expectations from you• Let’s focus on Software Projects• Keep away your day to day stuff for a while• Listen with an open mind Consider yourself as a child who has a fresh mind and is learning a new thing OR may be as someone who is offered a job to work as a scrum master• Don’t relate things to your work as you do it today – at least during the theory session• Don’t get stuck with the thought that it is all world of dreams and not possible practically
What is Scrum?• Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time.• It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month).• The business sets the priorities. Teams self-organize to determine the best way to deliver the highest priority features.• Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint.
Scrum has been used for Commercial software Video game development In-house development Satellite-control software Contract development Websites Fixed-price projects Handheld software Financial applications Network switching applications
Characteristics Self-organizing teams Product progresses in a series of two-to four-week “sprints” Requirements are captured as items in a list of “product backlog” No specific engineering practices prescribed One of the “agile processes”
The Agile ManifestoThe Scrum Framework implements the cornerstones defined by the agile manifesto Individuals and over Process and tools interactions Comprehensive Working software over documentation Customer over Contract negotiation collaboration Responding to over Following a plan change
What is a Sprint? In the Scrum Framework all activities needed for the implementation of entries from the Scrum Product Backlog are performed within Sprints (also called Iterations). Sprints are always short: normally about 2-4 weeks. Each Sprint start with two planning sessions to define the content of the Sprint: the WHAT-Meeting and the HOW- Meeting. The combination of these two meeting are also defined as Sprint Planning Meeting. In the WHAT-Meeting the Scrum Team commits to the User Stories from the Scrum Product Backlog and it uses a HOW-Meeting to break the committed User Stories into smaller and concrete tasks. Then implementation begins.
Sequential vs. overlapping developmentRequirements Design Code Test Rather than doing all of one thing at a time... ...Scrum teams do a little of everything all the time
No changes during a sprint ChangePlan sprint durations around how long you can commit to keeping change out of the sprint
Product owner Define the features of the product Decide on release date and content Be responsible for the profitability of the product (ROI) Prioritize features according to market value Adjust features and priority every iteration, as needed Accept or reject work results
The Scrum Master Primary job is to remove impediments to the ability of the team to deliver the sprint goal. Represents management to the project. Responsible for enacting Scrum values and practices. Ensure that the team is fully functional and productive. Enable close cooperation across all roles and functions. Shield the team from external interferences.
The team Typically 7-9 people Cross-functional: ◦ Programmers, testers, user experience designers, etc. Members should be full-time ◦ May be exceptions (e.g., database administrator) Teams are self-organizing ◦ Ideally, no titles but rarely a possibility Membership should change only between sprints
The WHAT and HOW Meeting (time-boxed: 8 hours) At the beginning of any Sprint (iteration 1-4 weeks), two half: * BackLog selection (WHAT to do) + Some of Product Backlog (user stories) will be chosen to be (time-boxed: 8 hours) At the beginning of any Sprint (iteration 1-4 weeks), two half: * BackLog selection (WHAT to do) + Some of Product Backlog (user stories) will be chosen to be Sprint Backlog. + Business value : is set by the Product Owner (client representative). -> represents PRIORITY: how Important the story is to the client. + Development effort : is set by the Team. -> represents COMPLEXITY: how Hard to implement the story according to the average developer’s experience. User Story: As a [USER] , I want [Feature X] so that [Y satisfied]
Planning Task * Task estimation (HOW to do) ◦ + each user story is broken down into concrete tasks, and for each task every group “votes” a number as “the estimated points” for the task. ◦ + Planning poker cards: for displaying the “voted/estimated” points. One task point is implicitly considered 1 man hour, for simplicity. (note: some may use 1 man day for 1 story point).
Planning Estimation * Task estimation (HOW to do) ◦ + If the points from the groups for the task are unanimous, or similarly (highest number is not higher than 1.5 the lowest number), the “final estimated points” is determined and marked into the task. ◦ + If the points of the group are not similarly (see above), the groups of highest number and lowest number will, in turn, tell the team why they think their number is suitable. After that all groups will re-estimate that task again. (this step may be repeated several times until a compromise is reached) ◦ + Total estimated points for a story should not exceed a predefined certain amount (20-40 man hours), otherwise the story may either be labeled as “epic” to be broken into smaller stories so as to not violate that limitation.
The Daily Stand-Up Time: short (usually 5-15 minutes)! It should start at the same time every working day (practically 15- 45 mins after start working time). Venue: near the collaboration space, i.e. near the Scrum taskboard enough to see the characters there. Agenda: Everybody tells others about his tasks, in 3 points: + What has he done since the previous stand-up ? (DONE’s yesterday) + What is he planning to do today ? (DO’s today) + Is there any obstacle preventing him/her from doing what he/she has planned ? (any IMPEDIMENT)
The Sprint Review Meeting Review meeting (time-boxed: 3-4 hours) ◦ internal showcase for whole team ◦ demonstrate what is being done ◦ direct feedback (incomplete features do not count) Typically takes the form of a demo of new features or underlying architecture No slides Whole team participates Invite the world
The Sprint Retrospective Retrospective meeting (time-boxed: 2-3 hours) (All Scrum team members raise their opinions about the Sprint, in 3 topics) ◦ what we did well? ◦ what did not go well? ◦ which improvement should be applied right next Sprint?
What is a Product Backlog The requirements A list of all desired work on the project Ideally expressed such that each item has value to the users or customers of the product Prioritized by the product owner Reprioritized at the start of each sprint
What is a Sprint Backlog Individuals sign up for work of their own choosing Estimated work remaining is updated daily Work for the sprint emerges If work is unclear, define a sprint backlog item with a larger amount of time and break it down later Update work remaining as more becomes known
Sprint Task BoardUser stories (with tasks) visible on a physical board.
The sprint Burndown chart Burn chart is a graphical representation of work left to do versus time. tracking the team’s progress & predicting when tasks will be completed how many story points the team can earn – the velocity. It helps predict delivery times based on
Definition of Done (DoD)In order to be able to decide when an activity from the SprintBacklog is completed, the Definition of Done (DoD) is used.It is a comprehensive checklist of necessary activities thatensure that only truly done features are delivered, not only interms of functionality but in terms of quality as well.The DoD may vary from one Scrum Team to another, but mustbe consistent within one team.There might be different DoD at various levels: ◦ DoD for a Scrum Product Backlog item (e.g. writing code, tests and all necessary documentation) ◦ DoD for a sprint (e.g. install demo system for review) ◦ DoD for a release (e.g. writing release notes)