2. Why?
• Give Dev team ability to provide working
software releases quickly
• Increase accuracy and stability of schedule
• Increase communication between Dev and rest of company
• Less time spent creating and updating documentation
3. Team Roles
• Kelly – Product Owner
• Matt – Scrum Master
• Woo – Team Member
• Jeremy – Team Member
• BJ – Team Member
• Mary Ellen – Team Member
• Lisa – Team Member
5. Definition of Done
What does it mean for something to be “complete”?
1. Code written per company standards and integrated
2. User story is accurately told
3. QA has written automated tests and the tests pass
7. User Story
As a <user>
I want to <do something>
so that <I get value>
8. Examples for the Client File
• As an auditor I want to see all records created
for a particular client so I can see their care
history.
• As a caseworker I want to see all records but
be able to go straight to a particular record so I
can make changes.
9. User Story
• Wireframes
• Acceptance tests
• Other details including
– Notes
– Even entire documents
– Priority
18. Sprint Begins
Daily standup meeting
• What tasks/stories since yesterday?
• What tasks/stories are you working on today?
• Is anything holding up your work?
– IT/Office issues
– Code issues
– Technical questions
– Anything else blocking progress
19. Daily Standup
• Short questions pertinent to team can be
asked in Daily Standup
• Longer questions should be held for after
• Work with Kelly to ask questions
25. Key Concepts
• Requirements broken into smaller pieces
called user stories
• Definition of Done – testing happens in
tandem with development
• Anything not “Done” at end of sprint is worth
0 points and returned to product backlog
26. Build Schedule Changes
dev7.kaleidacare.com qa7.kaleidacare.com solutions7.kaleidacare.com
• Build every night • Build weekly for • Build manually triggered
• Runs coded UI tests maximum consistency
• Developer check-ins • Used as an integration
no longer pushed to and staging area, not
dev7 website for QA testing
• Instead, gated
check-ins perform
code analysis and
other sanity checks
It is actually not too dissimilar from what we’re already doing.But with a few key changesThe terminology has changed so it may seem like a lot, but actually it’s not too far from what we’re already doing.
I want to spend a minute explaining why we’re doing thisGive Dev team ability to provide working software releases quicklyIncrease accuracy and stability of scheduleIncrease communication between Dev and rest of companyLess time spent creating and updating documentationFor example,Lisa, this means you won’t need to go back and update Requirement Documents anymore!
Kelly is the product owner. It means she chooses what we work on (but not how we do it).She will continue to work as the business intelligence expert for stored procedures and so forth.I am the Scrum Master. I facilitate the process and remove impediments.I will continue to work as the system architect.Most important - Everyone here is a team member.We’ll talk more about this later on.
I hesitated whether to include this diagram or notThe overall idea of being more agile is to do less AT A TIMEIt doesn’t mean we do less planning, it just means we do less planning UP FRONTIn order to help break work into small pieces, we break requirements into small pieces
Moving forward we’ll need to define what it means for something to be “complete”The definition we have proposed is that “done” means these 3 thingsYou will notice that an item is not “complete” until QA has tested and approved it As you’ll see, this means we have to break up requirements into smaller pieces of individual funtionalityYou turn some code in to QA as soon as you’re done and ideally they will test it the next day or twoIssues reported back to the developer very quicklyAnything that doesn’t have an automated test that passes is considered “not done” and is returned to the Product Backlog
User stories are the foundation of ScrumA requirement written from a users’ perspectiveShort and sweet – just one sentence but can have wireframes, acceptance tests, and additional details attached to it
This is a good template for thinking of user storiesThe key is that a user story is written in terms of a feature that matters to a user.This mostly affects Kelly
Here are some examples.All you need to get from this is that user stories are short, concise statements from a user perspective, HOWEVER…
They also have wireframes, acceptance tests, and other details attached to them
User stories can be group together into what’s called an “epic”In this example “Client File” would be the epicTogether these form the hierarchy of requirements
User stories can be further broken up into tasks“Tasks” are specific units of work that can be implemented
Here are some example tasksThey are very specific
User stories get placed on a Product BacklogKind of like our “After First Release” box in BackOfficeList of all work for a project prioritized as 1, 2, 3, 4 not 50 high priority itemsA backlog item is not a contract – just a promise for further communicationJust because something is on the backlog does not mean we are committing to itSome of the work may get done now, some may never get done
Here is what the product backlog looks like in TFSCan see User Stories expanded into specific Tasks
Once there are enough backlog items, it’s time to start planning a sprintFirst we estimate the effort of each story as a teamWe do this using Planning PokerAfter estimating the items on top of the backlog we can begin planning for this sprint
We have previous used the term, but not correctlyA sprint is a fixed 2 week time period, no matter whatAnything we don’t complete gets returned to the Product BacklogStarts with a Sprint Planning Meeting
If we go back to our product backlog choose the items that we agree to commit to do in the upcoming sprintWhatever we pick, we are now making a commitment that we will finish these items within that 2 week sprintWe move those items into a new backlog called Sprint BacklogRoughly similar to the current Dev Box, although nobody but the team can add items to itAfter choosing what we agree to take on, the sprint begins
Our daily standup meeting remains unchangedWe focus on these three questions
The “Task Board” contains all user stories for this sprint and the progress of each oneEach team member updates the progress on their stories within TFS every day before Daily Standup
As we go through the sprint, we will see the amount of work left steadily decreasingIf there are problems that slow progress, we can work with Kelly to remove stories from the sprint backlogIf things go really well, we can add additional storiesRemember the sprint time is fixed at 2 weeks no matter whatAnything not completed gets returned to the Product BacklogRemember “Definition of Done”
At the end of every sprint we gather the whole company together to show them what we’ve doneEach developer demonstrates his work to the groupAt this point the work is done and we’re just showing it offThe group may give feedback, which Kelly can record and later add to the backlog if she chooses to
Immediately following the Sprint Demo we’ll do a team-only retrospective where we can discuss what went well, and what we can improve.The idea is we’re constantly improving the process.
In order to accommodate this new process I think we’ll need to update our build schedule