Agile development and data with scrum and tdd
1 / 21

Agile Development and Data With Scrum and TDD - PowerPoint PPT Presentation

  • Uploaded on

Agile Development and Data With Scrum and TDD. Andy Leonard With thanks to Brian Knight, SQL Server MVP Scrum, Defined. Agile methodology Scrum is application of Agile Rugby term Self-organizing teams

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about ' Agile Development and Data With Scrum and TDD' - shelley-hardin

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Agile development and data with scrum and tdd

Agile Development and Data With Scrum and TDD

Andy Leonard

With thanks to Brian Knight, SQL Server

Scrum defined
Scrum, Defined

  • Agile methodology

  • Scrum is application of Agile

    • Rugby term

    • Self-organizing teams

    • Iterative approaches of 30 days called sprints

    • Adopt whatever engineering practice works for you

Agile development and data with scrum and tdd


Key Artifacts

Key Meetings

Development Process





  • Product Backlog

    • List of requirements & issues

  • Owned by Product Owner

  • Anybody can add to it

  • Only Product Owner prioritizes

  • Sprint Planning Meeting

    • Hosted by ScrumMaster; ½-1 day

    • In: Product Backlog, existing product, business & technology conditions

  • 1. Select highest priority items in Product Backlog; declare Sprint Goal

  • 2. Team turns selected items into Sprint Backlog

    • Out:: Sprint Goal, Sprint Backlog

Product Backlog


Product Owner: Set priorities

Sprint Planning Meeting

Sprint Review Meeting

Daily Work

Daily Scrum

Sprint: 30 days each

  • Sprint Goal

    • One-sentence summary

  • Declared by Product Owner

  • Accepted by team

Sprint Goal

  • Daily Scrum

    • Hosted by ScrumMaster

    • Attended by all, but Stakeholders don’t speak

  • Same time every day

    • Answer: 1) What did you do yesterday? 2) What will you do today? 3) What’s in your way?

  • Team updates Sprint Backlog; ScrumMaster updates Blocks List

ScrumMaster: Manage process, remove blocks

Sprint Backlog

  • Sprint Backlog

    • List of tasks

  • Owned by team

  • Only team modifies it

Blocks List


Team: Develop product

  • Blocks List

    • List of blocks & unmade decisions

  • Owned by ScrumMaster

  • Updated daily


  • Sprint Review Meeting

    • Hosted by ScrumMaster

  • Attended by all

  • Informal, 4-hour, informational

  • Team demos Increment

  • All discuss

  • Hold retrospective

    • Announce next Sprint Planning Meeting

  • Increment

    • Version of the product

  • Shippable functionality (tested, documented, etc.)

Product Backlog’

Stakeholders: observe & advise

The scrum master
The Scrum Master

  • Represents management to the project

  • Typically filled by a Project Manager or Team Leader

  • Responsible for keeping meetings short and direct and removing impediments

The scrum team
The Scrum Team

  • Typically 5-10 people

  • Cross functional

    • QA, Programmers, UI, DBAs, etc

  • Members should be full time unless role is minor (like sysadmin)

  • Teams are self-organizing

  • Optimally, membership only changes between sprints

Daily scrums
Daily Scrums

  • Daily and 15 mins at most

    • Can cancel the weekly status meetings!

  • Answer three questions:

    • What did you do yesterday?

    • What will you do today?

    • Are there any impediments in your way?

  • Not for problem-solving

  • Chickens and pigs are invited

    • Only pigs can talk

Sample roadblocks
Sample Roadblocks

  • My ____ broke and I need a new one today.

  • I still haven't got the software I ordered a month ago.

  • I need help debugging a problem with ______.

  • I'm struggling to learn ______ and would like to pair with someone on it.

  • I can't get the vendor's tech support group to call me back.

  • Our new contractor can't start because no one is here to sign her contract.

  • I can't get the ____ group to give me any time and I need to meet with them.

  • The department VP has asked me to work on something else "for a day or two."


  • Notes--Just a place to jot a note or two

  • Story--The story description ("As a user I want to...") shown on that row.

  • To Do--This holds all the cards that are not done or in process.

  • Tests Specified--I like to do "Story Test-Driven Development," which means the tests are written before the story is coded. I'm not a stickler about it but it does help when there's time to specify the tests (at a high level) in advance. This column just contains a checkmark to indicate the tests are specified. Ideally, not a lot of work (in the form of task cards) crosses this column without a checkmark in it.

  • Work In Process--Any card being worked on goes here. The programmer who chooses to work on it moves it over when she's ready to start the task. Often this happens during the Daily Scrum when someone says, "I'm going to work on the boojum today."

  • To Verify--A lot of tasks have corresponding test task cards. So, if there's a "Code the boojum class" card there is likely one or more task cards related to testing: "Test the boojum," "Write FitNesse tests for the boojum," "Write FitNesse fixture for the boojum," etc. Some task cards don't often get corresponding test cards ("Fix Bug #321 in Bugzilla") so those are placed in the "To Verify" column.

  • Done--Cards pile up over here when they're done. They're removed at the end of the sprint. Sometimes I remove some or all during a sprint if there are a lot of cards.


  • Usually 30 days in length

  • No changes allowed during this sprint unless team agrees

  • Need overlap

  • Need a theme for each sprint

    • “Make the application run on SQL Server in addition to Oracle”

    • “Convert to a new reporting structure”.

Sprint review meeting
Sprint Review Meeting

  • Entire team presents the iteration

  • Typically in form of demo

  • Very informal with 2-hour prep time rule

  • Participants

    • Customers

    • Management

    • Product Owner

    • Other engineers


  • Ken Schwaber is one of the originators of Scrum and has written two books on Scrum:

    • Agile Software Development with Scrum with Mike Beedle.

    • Agile Project Management with Scrum



Thank you
Thank You!