Your SlideShare is downloading. ×
Scrum in One Day
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Scrum in One Day

986

Published on

Published in: Technology, Business
0 Comments
5 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
986
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
45
Comments
0
Likes
5
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • 1. Ask why we are here2. Create an elevator pitch If we had 30 seconds and 2 sentences to describes our project, what would you say?3. Design a product box (write a small advertise article about the product)4. Create a NOT list5. Meet your neighbors6. Show the solution. High level blue print7. Ask what keeps us up at night. Do a Risk review8. Size it up9. Be clear on what’s going to give What’s most and less important : Time, Scope, Budget & Quality10. Show what it’s going to take.
  • 1. Ask why we are here2. Create an elevator pitch If we had 30 seconds and 2 sentences to describes our project, what would you say?3. Design a product box (write a small advertise article about the product)4. Create a NOT list5. Meet your neighbors6. Show the solution. High level blue print7. Ask what keeps us up at night. Do a Risk review8. Size it up9. Be clear on what’s going to give What’s most and less important : Time, Scope, Budget & Quality10. Show what it’s going to take.
  • Transcript

    • 1. Scrum in One Day Alexandre CuvaCoach Agile, LTM3, CSM, CSPO, HSPTP PMDay Bucharest 2012
    • 2. Practical Stuff
    • 3. Alexandre Cuva Email : Organizational Coaching alexandre.cuva@gmail.com (Management 3.0, Scrum) Twitter: @cuvaalex Team Coaching Blog: http://agile- alexcuva.blogspot.com/ (Scrum, XP, Kanban) Phone: +41 78 715 8309 Technical Coaching (TDD, BDD, C#, Java, Groovy) Agile Training (Management 3.0, Agile, Scrum, XP)
    • 4. Observation The complexity is growing fast
    • 5. Observation The current standard management system, does not provide satisfaction to all.
    • 6. “Organizations can become learning networks ofdiverse individuals creating value, and the roleof leaders should include the stewardship of theliving rather than the management of themachine.”http://www.stoosnetwork.org
    • 7. Agile OverviewAgile Tree Profit Practices Principles Values Source: Coaching Agile Teams by Lyssa Adkins
    • 8. Agile OverviewAgile 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 toolsWorking 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. Source: Agile Manifesto : http://www.agilemanifesto.org
    • 9. Agile OverviewAgile Principles1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.2. Welcome changing requirements, even late in development. Agile processes harness change for the customers competitive advantage.3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.4. Business people and developers must work together daily throughout the project.5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.7. Working software is the primary measure of progress.8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.9. Continuous attention to technical excellence and good design enhances agility.10. Simplicity--the art of maximizing the amount of work not done--is essential.11. The best architectures, requirements, and designs emerge from self-organizing teams.12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Source: Agile Manifesto : http://www.agilemanifesto.org
    • 10. Learning FrameworkSCRUM OVERVIEW
    • 11. Scrum OverviewScrum three Pillars Transparency Inspection Adaptation
    • 12. Scrum Flow Product Sprint Selected Sprint Backlog Planning 1 Product Backlog Planning 2 Vision Sprint Retrospective Backlog Review Meeting Daily Scrum
    • 13. Scrum a Learning FrameworkSCRUM ARTIFACTS
    • 14. Scrum ArtifactsVelocity the amount of product backlog that a team can handle in one single sprint Quantified in story points Story point is an arbitrary measure to quantify the required effort to finish an user story. Namely, how hard the story is. Loosely based on Fibonacci series. Business Solutions
    • 15. Scrum ArtifactsProduct BurnUp Display work delivered so far in the release to predict whether the release date will be met (extrapolation) Business Solutions
    • 16. Scrum ArtifactsProduct Release Burndown
    • 17. Scrum ArtifactsSprint Backlog The Sprint Backlog defines the work the Development Team will perform to turn Product Backlog items into a “Done” Increment. The Sprint Backlog makes visible all of the work that the Development Team identifies as necessary to meet the Sprint Goal. As new work is required, the Development Team adds it to the Sprint Backlog. As work is performed or completed, the estimated remaining work is updated. When elements of the plan are deemed unnecessary, they are removed. Only the Development Team can change its Sprint Backlog during a Sprint.
    • 18. Scrum ArtifactsSprint Burndown
    • 19. Scrum ArtifactsScrum Board
    • 20. Scrum ArtifactsDefinition of done When can a story be considered as “done” and accepted? Done defines what the Team means when it commits to “doing” a Product Backlog item in a Sprint. Exit criteria must be defined in advance for every individual User story at the sprint planning. E.g.: • Release (baseline created): label submission • Code Review conducted • Unit Tests successfully run and integrated with the CI system • Code coverage and static analysis done • Verified Business Solutions • Tests for regression automated and successful • Demo to the Product Owner for acceptance • User, API and Design documents completed Lingo term in the Agile religion for “done”: “sashismi”
    • 21. Learning FrameworkUSER STORIES
    • 22. User StoriesWhat is a User Story A user story describes functionality that will be valuable to either a user or purchaser of a system or software. User stories are composed of three aspects: • A written description of the story used for planning and as a reminder • Conversations about the story that serve to flesh out the details of the story • Test that convey and document details and that can be used to determine when a story is complete
    • 23. User StoriesEpics, Themes and User Stories User Stories Themes Epics
    • 24. User StoriesAttributes of a good user story Independent Avoid introducing dependencies cause this can lead to prioritization, estimating and planning problems Negotiable Stories are short descriptions of functionality, the details of which are to be negotiated with the customer. Important details shall be annotated as they surface Valuable to users or customers Avoid stories that only are valuable for developers Have the customer user or their representative write the stories Estimable If there are lack of knowledge, make a spike to gather further info Small Split stories (or combine them) into the right size Testable Developers must be able of determine when they are DONE
    • 25. User StoriesThe three aspect of user stories • Stories are traditionally written on note cards Card • Cards may be annotated with estimates, notes, etc. • Details behind the story come out during Conversation conversations between stakeholders, product owner and team • Acceptance tests confirm that the story was Confirmation coded correctly
    • 26. User StoriesFormat Business Solutions
    • 27. User StoriesExamples of user stories As a surfer, I want As a trader, I wantto ride the wave so open a position, so that I will have I can short a great fun. EURUSD pair.
    • 28. Retrospective
    • 29. Learning FrameworkTHE INCEPTION DECK
    • 30. The Inception Deck
    • 31. The Inception Deck2. The Elevator Pitch
    • 32. The Inception Deck3. Design the Box
    • 33. The Inception Deck4. Not List
    • 34. The Inception Deck5. Meet you neighbors
    • 35. The Inception DeckAnd the last 5 things to remember6. Show the solution.7. Ask what keeps us up at night.8. Size it up9. Be clear on what’s going to give10. Show what it’s going to take.
    • 36. Alexandre CuvaEmail : Organizational Coaching alexandre.cuva@gmail.c (Management 3.0, Scrum) om Team CoachingTwitter: @cuvaalex (Scrum, XP, Kanban)Blog: http://agile- Technical Coaching alexcuva.blogspot.com/ (TDD, BDD, C#, Java, Groovy)Phone: +41 78 715 8309 Agile Training (Management 3.0, Agile, Scrum, XP)

    ×