Please enable JavaScript.
Coggle requires JavaScript to display documents.
Cap05 (5.2) DELIVERING IN AN AGILE ENVIRONMENT (5.2 COMMON AGILE PRACTICE)
Cap05 (5.2) DELIVERING IN AN AGILE ENVIRONMENT
5.2 COMMON AGILE PRACTICE
5.2.1 RETROSPECTIVES
Retrospectives help the team learn from its previous work on the product and its process. One of the principles behind the Agile Manifesto is: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”
When the team completes a release or ships something. It does not have to be a monumental increment. It can be any release, no matter how small.
When more than a few weeks have passed since the previous retrospective
When the team appears to be stuck and completed work is not flowing through the team.
When the team reaches any other milestone.
5.2.2 BACKLOG PREPARATION
The backlog is the ordered list of all the work, presented in story form, for a team.
There is no need to create all of the stories for the entire project before the work starts—only enough to understand the first release in broad brushstrokes and then sufficient items for the next iteration.
Product owners (or a product owner value team that includes the product manager and all relevant product owners for that area of the product,) might produce a product roadmap to show the anticipated sequence of deliverables over time.
The product owner replans the roadmap based on what the team produces.
5.2.3 BACKLOG REFINEMENT
how long the refinement should be
Just-in-time refinement for flow-based agile. The team takes the next card off the to-do column and discusses it
Many iteration-based agile teams use a timeboxed 1-hour discussion midway through a 2week iteration. (The team selects an iteration duration that provides them frequent-enough feedback.)
Multiple refinement discussions for iteration-based agile teams. Teams can use this when they are new to the product, the product area, or the problem domain.
Consider using impact mapping to see how the product fits together. Under normal circumstances, the product owner leads this work. A servant leader can facilitate any necessary meetings as a way of serving the project.
backlog preparation and refinement meetings
Encourage the team to work as triads of developer, tester, business analyst/product owner to discuss and write the story
Present the overall story concept to the team. The team discusses and refines it into as many stories as required
Work with the team to find various ways to explore and write the stories together, making sure all of the stories are small enough so the team can produce a steady flow of completed work. Consider becoming able to complete a story at least once a day.
5.2.4 DAILY STANDUPS
Teams use standups to microcommit to each other, uncover problems, and ensure the work flows smoothly through the team.
Timebox the standup to no longer than 15 minutes. The team “walks” the Kanban or task board in some way, and anyone from the team can facilitate the standup.
What did I complete since the last standup?
What am I planning to complete between now and the next standup?
What are my impediments (or risks or problems)?
approach to standups
What do we need to do to advance this piece of work?
Is anyone working on anything that is not on the board?
What do we need to finish as a team?
Are there any bottlenecks or blockers to the flow of work?
Encourage any team member to facilitate the standup instead of a project manager or leader to ensure it does not turn into a status meeting, but instead is used as a time for the team to self-organize and make commitments to each other.
5.2.5 DEMONSTRATIONS/REVIEWS
As the team completes the features usually in the form of user stories, the team periodically demonstrates the working product. The product owner sees the demonstration and accepts or declines stories.
5.2.6 PLANNING FOR ITERATION-BASED AGILE
Each team's capacity is different. Each product owner's typical story size is different. Teams consider their story size so they do not try to commit to more stories than there is team capacity to complete within one iteration.
5.2.7 EXECUTION PRACTICES THAT HELP TEAMS DELIVER VALUE
Continuous integration.
Test at all levels
Acceptance Test-Driven Development (ATDD).
Test-Driven Development (TDD) and Behavior-Driven Development (BDD).
Spikes (timeboxed research or experiments).