Agile SharePoint Development With Scrum

  • 12,494 views
Uploaded on

Provide an introduction to Agile development using Scrum and discuss how the iterative approach to development helps the customer to get the solution they want. Look at how this approach works when …

Provide an introduction to Agile development using Scrum and discuss how the iterative approach to development helps the customer to get the solution they want. Look at how this approach works when applied to SharePoint projects, how it helps leverage more of the core platform and focuses effort on the biggest value areas. We will look at the challenges this brings to your development team by doing early integration, dealing with upgrades and changes and understand how addressing the hard things early is the right approach. We will also discuss how Scrum gives visibility of the project and brings both good and bad news. How getting customer engagement is the primary challenge and how the flexible approach is often at odds with the way work is contracted.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
12,494
On Slideshare
0
From Embeds
0
Number of Embeds
6

Actions

Shares
Downloads
680
Comments
1
Likes
12

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

Transcript

  • 1. Agile SharePoint Development with Scrum DEV338 Andrew Woodward, MOSS MVP
  • 2.
    • Andrew Woodward, MVP
      • Principal Consultant 21apps
      • Email [email_address]
      • Twitter @AndrewWoody
      • Blog www.andrewwoody.com/blog
      • Agile developer, recent white paper: Unit Testing SharePoint – Getting into the Object Model
  • 3. Agenda
    • Introduction to Scrum
    • Being Agile with SharePoint
      • Iterative Development
      • Expect Change
      • Upgrades
      • Environments
  • 4. Product Backlog
  • 5. Burndown Chart
  • 6. Sprint
  • 7. Product
  • 8. Product Backlog
  • 9. Roles
  • 10. Product Owner
  • 11. Release Planning Release 1 Release 2 Release 3
  • 12. Sprint ----5----10----15----20----25----30
  • 13. Estimating 5 8 3 2 8 13 8 21 5 2 5 8 Hours Story Points Bananas Days Release 1
  • 14. Priority 1 2 3 4 5 6 7 8 9 10 11 12 Release 1
  • 15. Sprints Release 1
  • 16. Potentially Shippable What is done?
  • 17. Sprint
  • 18. Burndown Chart Work to do Sprint duration in days
  • 19. Burndown Chart Work to do Sprint duration in days
  • 20. Velocity
  • 21. Release Planning Work to do Required Velocity Go Live Date
  • 22. Release Planning Work to do
  • 23. Release Planning Work to do Move Go Live Date
  • 24. Release Planning Work to do Reduce features
  • 25. Burndown Chart Work to do Early visibility
  • 26. Daily Scrum What I did yesterday? What I’m doing today Any problems I have.
  • 27. Scrum Master
  • 28. Product Backlog
  • 29. Bugs
  • 30. Bugs – Defect Backlog
    • Create Defect Log
    • Plan to do a couple of defect sprints
  • 31. Bugs - Fixed in Sprint
    • Directly related to task fix in Sprint
  • 32. Being Agile with SharePoint
  • 33. Iterative Development
    • Sprint
      • Potentially Shippable
      • Face tough challenges early and often
      • Ability to change every Sprint
  • 34. Continuous Builds and QA/Testing Proving / Staging Production
  • 35. Change
    • Expect Change
      • Design for change
        • Features and Feature Stapling over Site Templates
      • Tool Up
        • Upgrade helper utilities
  • 36. Upgrade
    • SharePoint is a long term proposition
      • More complex than traditional ASP.Net
    • Deal with early in manageable pieces
    • Attend DEV372 with Robert Bogue
  • 37. Environments
    • Developer
      • Automate refresh / consistent
    • Continuous / QA / Demo
      • Daily validation and Testing
      • Continuous customer access
    • Staging
      • Mirror Live, prove upgrades
    • Production
  • 38. Best Practice – Why?
    • Expect Change
    • Face tough challenges early
    • Know what is done
    • Visibility early and always
  • 39. Best Practice – When?
    • You have management buy in
    • You have customer buy in
    • You understand Why
    • Your team are committed
    • Start small
      • Inspect and adapt
  • 40. Best Practice – When its not?
    • Don’t start on High Risk projects
    • Don’t start without Management buy in
    • Don’t start without Customer engagement
      • Although agile can help rescue failing projects
    • Don’t start if the team don’t want to
  • 41. Question?
  • 42. Thank you for attending! Please be sure to fill out your session evaluation!
  • 43.  
  • 44. Thank you for attending!
    • Post conference DVD with all slide decks
    Sponsored by