An Intro to Agile Project Management with Scrum
•Als PPTX, PDF herunterladen•
2 gefällt mir•374 views
This document provides an introduction to Scrum and Agile development. It explains why the traditional waterfall model is being changed, describing how Agile methods allow for shorter development cycles with quicker feedback. It then outlines the Scrum framework, including defining the roles of product owner, scrum master, and development team. The document uses a house building analogy to illustrate how Scrum sprints can adapt to changing requirements. It also shows how user stories are broken down into tasks for sprints and how features are estimated in story points. Finally, it briefly describes key Scrum ceremonies like sprint planning, daily standups, and sprint reviews.
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Ähnlich wie An Intro to Agile Project Management with Scrum
Ähnlich wie An Intro to Agile Project Management with Scrum (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
An Intro to Agile Project Management with Scrum
- 1. ADAM LASKOWSKI Welcome to Agile An Intro to Scrum
- 2. WHY CHANGE? BUILD A HOUSE SCRUM QUESTIONS Agile
- 3. BUILD A HOUSE WHY CHANGE? SCRUM QUESTIONS Agile
- 4. Why? Responsive Short cycles means quicker feedback. More feedback leads to better deliverables. Reduces waste 20 percent of product features are used by 80 percent of your users. Short Feedback Loop Quickly respond to changes in your requirements or environment.
- 5. Individuals and interactions over processes and tools
- 7. Customer collaboration over contract negotiation
- 8. Responding to change over following a plan
- 10. Each release requires all features to be tested. The length of each dev cycle is different, and delays are common. Waterfall projects work on tasks in sequence (serial). Waterfall runs in sequence (serial)
- 11. Each iteration contain only a few features. Iterations are consistent intervals of time. Agile projects can easily work on tasks in parallel. Agile runs in parallel
- 12. WHY CHANGE? SCRUMBUILD A HOUSE SCRUM QUESTIONS Agile
- 13. Let’s Build a House! Living Room KitchenDining Room Office Master Bedroom Bathroom Bedroom
- 14. Let’s Build a House! Kitchen Master Bedroom BedroomBathroom
- 15. Let’s Build a House! Living Room KitchenDining Room Master Bedroom BedroomBathroom
- 16. Let’s Build a House! Living Room KitchenDining Room Nursery Master Bedroom Bathroom Bedroom
- 17. WHY CHANGE? BUILD A HOUSE LEAN QUESTIONS Agile SCRUM
- 18. Development TeamScrum MasterProduct Owner Meet the team!
- 20. PRODUCT BACKLOG SPRINT BACKLOG 2 WEEKS Story 1 Story 2 Story 3 Story 4 Story 5 Product Backlog Items (PBIs) Story 1 Task 1 Task 2 Story 2 Task 1
- 21. PRODUCT BACKLOG SPRINT BACKLOG 2 WEEKS 2 WEEKS2 WEEKS Story 1 Task 1 Task 2 Story 2 Task 1 Story 3 Task 1 Story 4 Task 1 Bug 1 Story 5 Task 1 Task 2 Story 1 Story 2 Story 3 Story 4 Story 5 Bug 1 Product Backlog Items (PBIs)
- 22. As a type of user, I want some goal so that some reason.
- 23. As a user, I can backup my entire hard drive. “ ”EPIC As a user, I can select folders I don’t want backup up so my backup drive isn’t filled with things I don’t need saved. “ ”STORY
- 24. Feature Estimation 1 2 3 Story Points 1 2 3 5 8
- 26. Sprint ReviewTask PlanningFeature Selection Sprint Anatomy Daily Standups Break down features into tasks that will fit into sprints. Developers choose features from the backlog based on priority and complexity. Usually takes the form of a demo given to the product owner, scrum teams, and sometimes customers. Share what you’re working on, and get help from your team when you’re work is blocked.
- 27. Sprints
- 28. WHY CHANGE? BUILD A HOUSE SCRUM QUESTIONS Agile QUESTIONS
Hinweis der Redaktion
- Frequent, iterative releases. Short feedback cycles = quicker revision / more value. Finding the 20% sooner means less waste. Get it in front of users. Changes in priority simply need a rework of the backlog before the next sprint. Long version: Agile focuses on frequent, iterative releases. This allows for shorter feedback cycles and results in better deliverables. If a product can be built quickly, it can be revised quickly in order to maximize its usability and value, and less valuable features can be dropped sooner. Finding the 20% of features that are used most often requires user interactions. The sooner your users can interact with a feature, the sooner you can find out if the feature needs to be there at all. Instead of releasing “the perfect version” of that feature, find out if anyone actually cares! Being able to react quickly is one of Agile’s strongest points. Backlogs are managed by feature priority, and changes in the specification simply require a rework in the backlog before the next sprint.
- Classic management -> assembly lines (predictable, repetitive). Now automated, left with chaotic, uncertain work. Self-organizing, cross-functional teams are better equipped. Long version: Many classic management techniques were born from assembly lines, which focused on precise execution of predictable, repetitive tasks. Today, most of the predictable, repetitive work is either trivially easy, or done by machines. What is left is the chaotic, uncertain work. Cross-functional, self-organizing teams are better at handling changes.
- Documentation is important, but authoring them up front has a heavy cost. If the feature is dropped, all that time writing a comprehensive doc is wasted. Keep it light, and improve as needed.
- Customers often need to see the wrong product before they know what they want. The quicker you can get a feature to a customer, the sooner they can tell you what they were actually looking for.
- Plans change throughout the project, often enough times where the final outcome doesn’t resemble the plan at all. Teams that can quickly respond to the ever changing needs of customers build better products.
- The biggest problem with this plan-driven release cycle is that our knowledge is never perfect at the start. Slow cycle impairs our ability to learn and adjust. Long version: Imagine water flowing from one bucket to the next. The requirements and design phases produce large specification documents that go into too much detail and end up getting changed in the process anyway. Development is told in some detail how they should implement each feature, often through architecture reference documents. The biggest problem with this plan-driven release cycle is that our knowledge is never perfect at the start. The cycle of feedback is slow, often very slow, and our ability to learn and adjust is significantly impaired. We might still have a great release and a good product, but with a lot of wasted time and effort spent of ideas that weren’t refined quickly enough.
- Work done in phases with handoffs. Design waits on research, dev on design signoff. New version, different cycle length, hard to predict. Delays are common. QA reviews massive pile of features, devs wait or move projects before review. High invest. Long version: Waterfall runs in sequence, with work being handed off to each department in phases. Design must wait for almost all research to complete. Developers must wait for all the designs to be signed off by project managers. Large tasks that aren’t broken down cannot be worked on simultaneously by multiple business groups. Each version of the product often has a different cycle length, so it is harder to accurately predict when a release is possible. Delays are very common and can prevent any kind of release from happening. QA gets a large number of features to test all at once each release. Developers wait for feedback before they can start bug fix, and others are off to new projects before their code is fully scrutinized. The value of features that designers and dev believed useful isn’t tested until after the heavy time investment.
- Sprints create iterative, potentially shippable, work. Each piece can be reviewed while the next is built. Eventual continuous research/design. One week to one month, easier estimation, much more predictable release times. Smaller batches, devs work on next batch while first batch is reviewed by devs. Long version: Instead of using activity-based phases, Agile projects are broken down into fixed-length iterations, called called sprints. Each sprint focuses on increments of completed, and potentially shippable, work. These pieces can be tested and reviewed by the customer while next pieces are being researched, designed, and developed. Eventually, we hit a point of continuous research, continuous design, etc. Iterations are typically between one week and one month, and once a length is chosen, all iterations use that timeframe. This makes releases easier to predict, and a delayed feature can move to the next iteration instead of delaying the current release. Releasing only a few intended features gives QA and test users time to provide feedback without blocking development work. Devs are busy working on the next groups of feature while their previous work is validated, both for functionality, and desirability. It’s a terrible feeling when you spend a lot of time polishing a feature no one will use.
- House analogy. Building a house has requirements that you need to fulfill in a fixed amount of space. Normally, you get all the structure finished, then you start filling in walls and setting up rooms. (Whole story is about 5 minutes).
- Finish the important rooms first, the ones you know you can’t live without.
- 6 months into the project, wife gets pregnant, and you need a nursery more than you need that office. You build your living room and dining room space while you’re busy working on the specs for the new nursery.
- Since you were working on each room by priority, you were able to adjust your final version to your change in requirements without that much cost, because no work had yet been done on the lower priority rooms when your needs changed.
- Meet the team! Product managers are responsible for adding and prioritizing features, or stories, within the backlog. A scrum master’s job is not only to coach and mentor, but to keep their team free from distraction. This includes interfacing with external stakeholders or other teams, as well as helping remove other roadblocks when they can. Teams are the backbone of your organization. In the Scrum framework, they are told what to do, but not how to do it, leaving them to self-organize.
- A Scrum team’s goal is to produce a product increment every sprint. The increment may not yet include enough functionality for the business to decide to ship it, but the team’s job is to ensure the functionality present is of shippable quality.
- Product owner prioritizes backlog. Ranked and visible to org, sets expectations with stakeholders. Eng time becomes fixed asset. PBIs normally stories, bugs. Broken down to tasks at start of sprint. In agile development, the product owner is tasked with prioritizing the backlog–the ordered list of work that contains short descriptions of all desired features and fixes for a product. Items are ranked by the product owner, and the backlog is visible to the rest of the organization. This helps set expectations with stakeholders and other teams, especially when they bring additional work to you, and makes engineering time a fixed asset. Items usually consist of user stories and bugfixes. Each item is broken down into tasks once a team has added it to their sprint, allowing them to divide the labor among their team. The PBI focuses on the what, while the tasks focus on the how.
- At the end of each sprint, the team will meet to review the current product backlog and discuss any possible reprioritizations
- Story = requirement with context. Tells you why you want build, and how the user will interact. A story is a quick way to describe a requirement with a bit of context, so that the team knows who to talk to for more details and what problem the feature is trying to solve. The purpose of writing a User Story is to help provide additional context to the team. It not only tells you why you want to build it, but gives an idea of how a user will interact with the feature, thus guiding how it should be built to fill this expectation.
- Estimates show relative complexity, using arbitrary units. They do not representtime. Once the initial backlog is built, engineering will meet with the product owners and give estimates to the stories. Story estimates help drive the ranking and scheduling that happen in release planning and iteration planning. Estimates, by nature, are inaccurate, and represent a rough idea of how long your task will take. It’s common for stories to be broken down further, and the backlog to be reprioritized after an estimate meeting. In Agile, features are measured in arbitrary units. The units do not represent time, but represent relative complexity between features. Some companies use a 1-3 scale, because it’s easy for the human mind to measure things on a 3 point scale. Others use fibonacci numbers to give a larger scale.
- It’s very likely that your teams will miss their first several estimates. The estimates are relative, and the first few sprints will require guesswork because you won’t have enough data to compare against. When you miss your estimate, adjust the next sprint’s estimate based on what your team was able to achieve last sprint. Over time, your estimates will be more accurate. You will then have an idea of your team’s velocity.
- Story estimates drive scheduling on the backlog. Task estimates drive resource allocations during a sprint. Standups let your team know what you’re working on, and if you’re stuck. Get advice in a forum. Sprint review usually involves a demo, with minimal prep. Let the product speak for itself. Long version: Story estimates drive scheduling on the backlog. Task estimates drive resource allocations during a sprint. Developers will select features from the backlog based on their priority, and can then break them down further into tasks in order to assign them to the team. Standups let your team know your progress, but more importantly, they give you a chance to ask share your roadblocks in a forum, so you can get advice or help from your team when you’re stuck. The Sprint Review is used to assess if the team successfully completed the goal of the spring. It often comes in the form of a demo, and is encouraged to be done with minimal preparation for the meeting. Let the finished product speak for itself.