04 Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Transcription

1 Agile Quick Facts AGILE PRINCIPLES Customer Satisfaction 01 Changing Requirements 02 Frequent Delivery 03 Collaboration 04 Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer s competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project. Motivated Individuals 05 Face-to-Face Conversation 06 Working Software 07 Sustainable Pace 08 Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.. Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Technical Excellence 09 Simplicity 10 Self-Organizing Teams 11 Retrospection 12 Continuous attention to technical excellence and good design enhances agility. Simplicity, or the art of maximizing the amount of work not done, is essential. The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. 1

2 AGILE TERMINOLOGY Acceptance Criteria The Acceptance Criteria are used to judge if user stories have been successfully implemented and tested. The criteria are expected to be all or nothing - that is, all criteria must pass or the story is not done. Iteration/Sprint An iteration or sprint is a 2-4 week block of time. At the end of each sprint, the development team demonstrates working software to the Product Owner. We also review, plan and set team goals for improvements for the next sprint. Product Backlog The backlog is a prioritized list of user stories and defects, in order from most valuable to least valuable, for a system. Backlogs include both functional and non-functional User Stories as well as technical team-generated stories. Product Owner A Product Owner represents the stakeholders and manages the Product Backlog, addresses questions that arise during development and signs off on work results. Roadmap & Release Plan The Roadmap and Release Plan provide a high-level plan for navigating from sprint to sprint. When needed, milestones for working with impacted teams can be determined during release planning. ScrumMaster The ScrumMaster is a facilitator and team leader who motivates and helps to enforce team rules. The ScrumMaster can also help clear impediments when necessary. Story Points Story points are a relative scale of effort required by a team to implement a User Story. Each story will be given a numeric score of 1, 3, 5, 8, 13 or 20. The score represents the level of effort relative to the other stories in the backlog. Task Board The Task Board is used to track daily activity and is the focal point for discussion during the Daily Scrum. The Task Board also helps to keep daily tasks visible to the entire team. User Story As a [who], I want [what] so that I can [why]. A traditional requirement will define the what. A User Story fills in the gaps by defining the who, what and why of each requirement. Velocity Velocity is the total number of story points a team can complete in one sprint. 2

3 AGILE TIPS 01 Identify Dependent Teams Early Send an impact request to all teams and invite a representative from each team to a kickoff meeting. During this meeting share an overview of Agile and the vision statement for the product. This will help set expectations for the future. 02 Architecture Can Provide Flexibility When working with external Waterfall teams, consider architecture that will provide flexibility in implementation. This will provide more flexibility in future planning. Example: A mock-data architecture allows our team to build the UI with stubbed data then integrate with external services as they become available. This approach provides flexibility to continue Agile time-boxed development while working with external Waterfall teams who are not Agile, therefore not working at the same cadence with the same timeline. Align Dependencies to Release 04 Plan Plan when deliverables from dependent teams will be required within the release plan. Set baseline due dates for analysis, design, build, and test, and communicate this to dependent teams. Example: Include phase milestones for dependent teams as part of the roadmap and release plan. Split User Stories 05 Splitting stories into small, logical units provides flexibility in release planning and, ultimately, a more accurate measure of team velocity. Example: Use a mock-data framework and split user stories into separate UI with Stub data and Integration stories. Score each story. This allows the team to plan parts of the same functional requirement in different sprints, if needed, while still demonstrating end-to-end functionality. 03 Align Dependencies With Roadmap When creating the product roadmap, mark where dependencies intersect with roadmap. Example: The name of each dependency is placed on a sticker. Each sticker is placed on the Product Roadmap in relation to the functional theme(s) it will impact. This will help the team visualize external dependencies within the roadmap and potential impacts to the release planning. Keep Dependent Team Visible 06 Add an Impacted Teams story to each sprint within the release plan. The user story may be the same across sprints, however, the acceptance criteria for this story will change based on the effort for each sprint. Re-score this story with each sprint to reflect the commitment and e current sprint. Example: Maintain a section in the task board for tracking deliverables through the Waterfall phases. Provide status updates to dependent teams. 3

4 AGILE 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 Working Software Customer Collaboration Responding to Change O V E R Processes and Tools Comprehensive Documentation Contract Negotiation Following a Plan That is, while there is value in the items on the right, we value the items on the left more. TIPS FOR DISTRIBUTED TEAMS Use conference line and online meetings for collaboration. Provide Agile training for all team members. Use an online tool or publish a high-resolution picture of the sprint wall each day. Provide access to Product Backlog and other design documents. Offshore teams hold a separate Daily Scrum meeting. Designate a team lead to work offshore with the offshore team. This person is also the ScrumMaster for the offshore team. 4

5 SCRUM NING HORIZON FIVE LEVELS OF NING LEVEL WHO WHAT OUTLOOK O1 O2 O3 O4 O5 SPRINT LEVEL RELEASE LEVEL PRODUCT LEVEL O1 O2 Identify Themes, Epics & Features Backlog Creation O3 RELEASE Backlog Refinement O4 SPRINT Story Review O5 PRODUCT VISION PRODUCT ROADMAP DAILY CONTINUOUS RE-NING (Recommended) Product Owner Product s Elevator Pitch Long-Term, revised every 6-12 months Managed by: Product Owner Contributers: Stakeholders, Team Members Product Management & Program Team, Stakeholders, Stakeholders Identify Business & Technical Epics & Features Create the Product Backlog (user-story level) Provides visibility on how to deliver resources, timing and backlog priority Additional story details, estimating & prioritizing Create Sprint Backlog Review story details for upcoming sprint revised quarterly 3-6 months, revised as needed revised every 8-12 weeks weeks, forward-looking 2-4 months, revised after each sprint 2-4 weeks, leading into each sprint ScrumMaster, Daily Scrum Every day Revised daily Product Owner, ScrumMaster, High-Level Product Plan/ Approach to Delivery Re-plan as necessary Rinse & repeat (Sidebar/Huddle/Swarming) Revised quarterly Ongoing, continuous Tactical Strategic 5