introduction to scrum

presented at moftaksolutions

Transcript

1. SCRUM Introduction Najam Sikander Awan @najamsikander
3. Agile • Being adaptive • Iterative development • Minimize need for meetings • Different methodologies to reach it • Minimize risk • So many unknowns makes it hard to predict time and resources (cost) https://speakerdeck.com/moonglum/scrum
4. Agile Methodologies • Lean and Kanban • Scrum • XP • Tools: TDD, Pair Programming, Continuous Integration, Continuous Deployment
6. • Do as much as possible within fixed time and resources • Functionality ▫ How do you make sure you can deliver functionality? • Create knowledge? ▫ How do you make sure you create knowledge? • Productivity? ▫ How do you achieve highest productivity?
7. Done???
8. Definition of Done • Meeting all the requirements • Compliance with development process. ▫ Unit tests ▫ Integration tests ▫ Minimal documentation ▫ Demo and approval from project owner
9. Values • Individuals and interactions over process and tools. • Working software over comprehensive documentation • Customer collaboration over contract negotiation • Responding to change over following a plan Reference: Agilemanifesto.org
11. The Team • Product owner • Development team • Scrum Master • Stack Holders (managers from other departments, share holders, investors)
12. Development Team • Work on the product • Manage their own work • All skills necessary to increment the product • The entire team is accountable for the whole • Sole responsible for estimations • 3 to 9 people
13. Scrum Master • Ensure that scrum is understood and team adheres to it. • Manages interaction with outside world • Coaching, helping the process • Facilitate scrum events as requested.
14. Scrum Events Event Duration Sprint Planning Meeting < 8 hours Daily Scrums < 15 minutes Sprint Review < 4 hours Sprint Retrospective < 3 hours
15. User Stories • Invest ▫ Independent ▫ Negotiable ▫ Valuable ▫ Testable • As a [role] I want to able to [something] so that [benefit].
16. Acceptance Testing • Integration Testing ▫ End to End • Tests a user story • Prevents breaking pages later on. • Written with the domain expert (sales manager, customer support manager etc).
17. Feature: Fight or flight In order to increase the ninja survival rate, As a ninja Commander I want my ninjas to decide whether to take on an opponent based on their skill levels. Scenario: Weaker opponent Given the ninja has a third level black-belt When attacked by samurai Then the ninja should engage the opponent Scenario: Strong opponent Given the ninja has a third level black-belt When attacked by “sultan rahi” Then the ninja should dial 15 and And he should start running for his life.
18. #1. Get your Backlog in order • Find willing Product Owner ▫ Responsible for prioritizing work on the product. ▫ Who knows what is required of the product. ▫ Person with good communication. ▫ Committed for product success. ▫ Willing to dedicate reasonable time for development. • Scrum Master ▫ Supporting the scrum team. ▫ Coaching and guiding them through this process. ▫ Removing impediments blocking team progress.
20. #1. • Create the product backlog ▫ List of things that people want to be done ▫ Anyone can add anything (Features, bugs, risks, non-functional item, even items you will never develop) ▫ Only PO can order items in backlog ▫ Things on top will shipped first. Some recommend features written in form of user stories. ▫ If you feels some risk put in backlog if PO decides this should be lower in order than ownership of the risk is transferred to PO
21. #2. How to estimate your product backlog • High level estimates ▫ provides idea of the size of backlog items. Helps to inform the decision about priorities. ▫ Estimate your product backlog in points. Not in units of time. ▫ Ask team how big is it? Against each back log item.
23. #2. • Use a point system ▫ Fibonacci numbers (1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233, 377, 610, 987) ▫ 1-21 range for enhancements and bug fixes in the BAU(Business as usual) cycle ▫ Assign points to each item relative to other. ▫ Start with smallest assign it 1 then find biggest assign it 21.
24. #2. • Estimate as a Team ▫ Wisdom of Crowds, collective thinking ▫ Planning poker – new/weak and old/strong estimators both got equal chance. ▫ Negotiate the size of each backlog item as a team ▫ Size enough of back log • Review Priorities ▫ PO should again look at priorities they might need to arrange again if something is complex and might block other features • Stick with the program ▫ Learn scrum well before adapting this step (sizing backlog)
25. #3. Sprint Planning • Sprint planning workshop ▫ Team attends. All roles (business analysts, testers, developers, PO) • Decide your sprint duration as a team ▫ Team with immature processes have to deal with overhead of testing, deployment and review for a short cycle
26. #3: • Keep sprint duration consistent ▫ Get you into rhythm, makes your process very repeatable ▫ Allows you to understand how many backlog points you can typically do in a sprint • team selects target backlog for sprint ▫ Stretch items in case team finishes early ▫ In future this decision can be accurate with the help of recorded velocity
27. #3: ▫ Velocity is the number of backlog points delivered in a sprint. Fluctuate a lot initially but settles down as team get experience. • Clarify sprint requirements ▫ Each item is explained by PO, team discuses item in detail asks question. Capture discussion in user stories. ▫ User story can be backed by wireframe with annotations and comments
28. #4. Sprint planning/estimate tasks • Breaking the requirements into tasks and estimating the hours to complete them done by whole development team. • Set the sprint budget ▫ Available number of hours the team has to work on the sprint. ▫ Deduct time for meetings, other projects, support
29. #4. • Break requirements into tasks ▫ For each BI design, development, unit testing, system testing, UAT and documentation ▫ If possible define tasks as deliverable. • Estimate tasks in hours ▫ Keep tasks small, break big tasks into smaller task of 8 or 4 hours. ▫ Smaller task are easy to estimate and provide some accurate estimates. By the end of the day they are either done or not.
30. #4. • Commit to the sprint backlog ▫ Add tasks estimates if they are over sprint budget reduce them. ▫ Team should commit to deliver the items in sprint backlog • Identify stretch tasks
31. #5. Create a collaborative workspace • Whiteboards: ▫ roadmaps, key dates, ideas, stats, status reports, • Create a place for collaboration ▫ Near white board, stand up meeting for status during sprint • Management by post-it note ▫ Kanban product backlog, tasks to-do, work in progress, verify, live/done [picture]
35. #6. sprint • Agile team must be empowered ▫ Team makes decision, solved their own problems, mange themselves. • Time waits for no man ▫ Duration of sprint is fixed, add to scope if you take out something. Reduce scope to if you are going to miss deadline. • Done means done ▫ Complete one feature at a time before moving to next ▫ Its better to have 100% of something over 90% of everything • Testing is integrated throughout the lifecycle ▫ Writing unit test before writing code. ▫ Testing each feature
36. #6 • No interference please ▫ Let the team work on what they have committed too. Constant changes to priorities prevent a development team from delivering at all. ▫ If you add 3 hours of work take out 6 hours of work at least. • Aborting a sprint ▫ PO can abort. If sprint goal is no longer applicable. ▫ Or something important requires to re focus whole team.
38. #7. Stand up and be counted • Whole team must be present in daily standup meeting. Each member reports to team by answering ▫ What have they achieved since the last meeting? ▫ What will they achieve before next meeting? ▫ Is anything holding up their progress? ▫ Scrum master responsible for keeping this meeting focused, keeping it timely and ‘on topic’
39. #7 ▫ SM should also remove impediments fast. ▫ Choose a penalty if someone is late for standup team decide what to do with it when scrum ends.
40. #8. Track progress with a daily burn down chart • Take all the tasks in sprint from step4 update the estimated timed time to complete each task daily • Team members take responsibility to update ETC for their own tasks. ▫ Be honest about it regardless how long has been spent to date and what was estimated initially • Team goal is to reach zero hours.
41. Burn down charts
42. #8. • Plot graph as a visual progress indicator/report • With speech bubble annotate key event on graph • Burn down charts highlights problem if any they don’t solve them
43. #9. Finish when you said you would • 80% of features, 100% complete might be a shippable product. • When your time is up your have more important features completed to ship • Complete each features before moving on to the next. • Manage your code carefully so you build a shippable product at anytime.
45. #10. Review, reflect, repeat • Sprint Review ▫ Team conduct this meeting after sprint ends along with stack holders. ▫ Review what was delivered in the sprint. Demo the software ▫ Every member gives demo to the features they have worked on ▫ Stack holders gives their input on each feature ▫ Team stay focus on deadline so they have something to demo on sprint review.
46. #10 • Sprint retrospective ▫ Held after sprint review PO can be invited. ▫ Team review whole sprint and discusses following Review the final burn down chart to check if they deliver their commitments from this we can create another graph to show team success rate and that would tell us if its getting better or not. Review team velocity and record it into a graph overtime we will have enough data that would help us estimate better.
47. 10 • Sprint retrospective ▫ Discuss what went well ? It should repeat next time ▫ Discuss what could have gone better? Try to understand why ▫ Decide what the team will do differently in the next sprint? (select few action points for next sprint) ▫ This is a continuous learning process
48. 10 • Repeat ▫ Takes 3 to 4 sprints to get into a rhythm.