SCRUM: agile software development
•Download as PPTX, PDF•
1 like•108 views
This document provides an overview of agile software development and Scrum methodology. It describes agile as an iterative process with continuous delivery of working software in sprints. Scrum is defined as a framework to address complex problems while delivering high value products. Key Scrum elements include cross-functional self-organizing teams consisting of a Product Owner, Scrum Master, and Development Team. Events include sprint planning, daily scrums, sprint reviews and retrospectives. Artifacts include backlogs, user stories and burndown charts.
More Related Content
What's hot
What's hot (20)
Similar to SCRUM: agile software development
Similar to SCRUM: agile software development (20)
More from AGILEDROP
More from AGILEDROP (14)
Recently uploaded
Recently uploaded (20)
SCRUM: agile software development
- 2. Agenda - Short overview of agile way of software development - Short overview of agile methods, - SCRUM overview, - Roles, - Aspects
- 3. Agile - Iterative process to build software incrementally, - Continuous delivery of user stories each sprint, - Continuous activities. Traditional Agile One-off activities Continuous activities Incrementally Instead of once
- 4. Agile - Adaptive planning - Requirements can change, - Measure (productivity) = working software (actual value for customer),
- 5. Agile - benefits - Quality and visibility improvements from the beginning of the project, - Reduced risk (early feedback), - Happy customers
- 6. Agile methods - Scrum, - Kanban, - Lean, - Extreme programming (XP).
- 8. SCRUM definition “A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.”
- 9. SCRUM - Lightweight, - Simple to understand, - Hard to master, - Consists of scrum team - Roles, - Events, - Artifacts, - Rules.
- 10. SCRUM theory - Founded on empirical process control theory, - Empirical - knowledge comes from experience and making decisions on what is known, - Transparency (process visibility), - Inspection (frequent artifact inspections, prevent variances), - Adaptation (divergence exists, something has to be adjusted), - Sprint planning, daily scrum, sprint review and sprint retrospective.
- 11. SCRUM team
- 12. SCRUM team - Self-organizing and cross-functional, - Product owner, - Scrum master, - Development team
- 13. SCRUM team - product owner - Manage the product backlog, - Clearly express the product backlog items, - Order the items (tickets, issues, features) to best way to achieve goals, - Optimize the value of the work the development team performs - Ensure product backlog is visible, transparent and clear, - Ensure that development team understands the items, - “Voice of the customer”
- 14. SCRUM team - development team - Deliver a potentially releasable increment of “Done” product, - No sub teams, - Accountability belongs to the development team as a whole, - Consists of developers and scrum master, - 3 to 9 people, participating in scrum events, dedicated and empowered.
- 15. SCRUM team - scrum master - Ensure that scrum is understood and approved, - Support product owner and development team in many ways, - Entire organization of events, - Protect and encourage the team, - Planning and tracking of scrum process, - Improve the process.
- 16. SCRUM events - sprint
- 17. SCRUM events - sprint planning - Define the work to be performed during sprint, - Max 8 hours time-boxed (define “what can be done in this sprint”) - Based on capacity of dev team, - Based on past performance of the team, - Define the sprint goal and present it to dev team, - Team decides how the functionality is built (ticket refinement).
- 18. SCRUM events - fist of five - 5 fingers - I believe we are going to complete this sprint, no problem, - 4 fingers - I believe we have a really good chance we complete the sprint, - 3 fingers - I think we might make it or not, some doubt, - 2 fingers - I have serious doubts, - 1 finger - There's no way we complete this sprint.
- 19. SCRUM events - daily scrum - Time-boxed 15 minutes, - Development team syncs activities and creates plan for next 24hrs, - 3 questions - What I did yesterday? - What I am doing today? - Do I see any obstacle in the path towards the sprint goal? - Benefits - Improve communication, - Eliminate other meetings, - Identify obstacles, - Promote quick decision making.
- 20. SCRUM events - sprint review - At the end of the sprint increment is inspected, - Time boxed (dependent on the length of sprint, 4h - 1 month), - The result is a revised product backlog that defines the probable product backlog items for the next sprint, - Scrum team, key stakeholders, - PO explains what has been done and what has not, - DT discusses what went well, what problems they encountered and how they were solved, - DT demo the done work.
- 21. SCRUM events - sprint retrospective - Scrum team inspects itself and creates a plan for improvement, - Time boxed (1 month sprint, 3h), - Inspect how last sprint went regarding the people, process, tools, - Identify major items that went well or did not, - Create a plan for implementing improvements (KAIZEN)
- 22. SCRUM artifacts - User stories, - Story points, - Planning poker, - Product backlog, - Sprint backlog, - Burndown chart.
- 23. User stories - Customer wishes, - Each story is captured as separate item in product backlog, - Independent on other user stories, - As a <user> - I want <function> - So that <desired result>
- 24. Story points - Estimate level of effort expected to develop, - Relative measure of feature difficulty, - Fibonacci numbers (0,1,2,3,5,8…), - Planning poker
- 25. Story points - planning poker
- 26. Product backlog - List of all product features, - Can contain bugs, non-functional items, - Items can be added by anyone, - Each item should have business value assigned, - Maintained by product owner
- 27. Burndown chart - Remaining work in the sprint, - Calculated in hours remaining, - Maintained by scrum master
- 28. Thank you for attention
Editor's Notes
- Agile is a time boxed, iterative approach to software delivery that builds software incrementally from the start of the project, instead of trying to deliver it all at once near the end. It works by breaking projects down into little bits of user functionality called user stories, prioritizing them, and then continuously delivering them in short two week cycles called iterations. You are never done analysis, design, coding and testing on an Agile project. So long as there are features to build, and the means to deliver them, these activities continue for the duration of the project.
- Through a combination of good practices, and open and honest planning, agile way accept and embrace change even late in delivery process. The rate at which teams can turn their customer's wishes into working software the productivity. Project plans, test plans, and analysis artifacts are all well and good but they intelfs are no value to the end customer.
- Quality improves because testing starts from day one. Visibility improves because you are half way through the project when you have built half the features. Risk is reduced because you are getting feedback early, and Customers are happy because they can make changes without paying huge costs.
- For the beggining i would like to present you this image. I think it’s great presentation how project is being bounced in different states in a different roles which leads to chaos to have potentialy stable and shippable product which could help customer to achieve his business goals. For example customer would like to have a swing, but he was billed for a roler coaster and got a few wires hanging on a tree doing whatever it is - because it was not documented properly.
- What is complex adaptive problem? Is a problem which is not well understood and must be brought up into focus by transparency, inspection and adaptation.
- Transparency - aspect of the process must be visible to those who are responsible for the outcome. Share common definition of done (that means everybody knows clearly what needs to be done). Inspection - scrum masters frequently inspect artifacts and progress toward the spring goal. By this scrum master will detect undesirable variances. Artifacts are product backlog, sprint backlog and so on… Adaptation - if scrummaster detects divergences then something have to be adjusted within the acceptable limits. Those pillars are done in four formal events - sprint planning, daily scrum, sprint review and sprint retrospective.
- Self organizing team choose how to accomplish their work in their best way with all competencies needed to accomplish the work without depending on anyone else who’s not part of the team There are 3 roles - product owner, scrum master and development team
- Product owner - is sole person who is responsible for managing the product backlog. This includes - clearly expressing the product backlog items Voice of the customer - PO discuss and agrees with stakeholders what to do, why and when to release the product.
- Increment = a piece of done product
- It supports product owner and developments team such as gathering important informations whihc are missing He is repsonsible for organizting all the events
- Scrum events are timeboxed - it’s called sprint. Sprint is normally 2 to 4 weeks long and it starts immidiatly after the closure of previous sprint. During the sprint there are NO changes made which could danger the sprint goal, quality goals also does not decrease. Each event is formal opportunity to inspect and adapt something.
- During sprint planning we define the work to be performed in the sprint. The sprint goal is an objective set for the Sprint that can be met through the implementation of Product Backlog.
- When we start a new sprint, we measure the confidence the team has of completing that sprint. This is done with a ‘Fist of five’ where are some general rules
- Happens at the end of the sprint to inspect the increment and adapt the product backlog if needed
- Kaizen - je proces stalnega izboljševanja
- Kaizen - izboljšava
- Planning poker is a procedure where scrum team adds story points for each of the task.
- Planning poker is a procedure where scrum team adds story points for each of the task. How does it look like - scrum master organize short meetings and prepare board where developers can vote for each task. Scrum master present the task and open voting for this task. After 1 minute or 2 minute the voting close and based on majority of team vote the story point for the task is set. There can be some adjustments if 2-3 people vote differently.
- Chart showing how much work remaining in a Sprint Calculated in hours remaining Maintained by the Scrum Master daily
- Chart showing how much work remaining in a Sprint Calculated in hours remaining Maintained by the Scrum Master daily