Path to agility

Editor's Notes

• #2: 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.
• #3: 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!
• #4: 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.
• #5: 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
• #6: 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
• #7: 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
• #8: 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
• #9: Here are some examples.All you need to get from this is that user stories are short, concise statements from a user perspective, HOWEVER…
• #10: They also have wireframes, acceptance tests, and other details attached to them
• #11: 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
• #12: User stories can be further broken up into tasks“Tasks” are specific units of work that can be implemented
• #13: Here are some example tasksThey are very specific
• #14: 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
• #15: Here is what the product backlog looks like in TFSCan see User Stories expanded into specific Tasks
• #16: 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
• #17: 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
• #18: 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
• #19: Our daily standup meeting remains unchangedWe focus on these three questions
• #21: 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
• #22: 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”
• #23: 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
• #24: 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.
• #27: In order to accommodate this new process I think we’ll need to update our build schedule