Open Framework, Information Management Strategy & Collaborative Governance | Data & Social Methodology - MIKE2.0 Methodology
Wiki Home
Collapse Expand Close

Collapse Expand Close

To join, please contact us.

Improve MIKE 2.0
Collapse Expand Close
Need somewhere to start? How about the most wanted pages; or the pages we know need more work; or even the stub that somebody else has started, but hasn't been able to finish. Or create a ticket for any issues you have found.

Agile Iteration Management

From MIKE2.0 Methodology

Jump to: navigation, search
Under review.png
This article is a stub. It is currently undergoing major changes as it is in the very early stages of development and is only a placeholder. Please help improve MIKE2.0 by adding to this article.

Agile Iteration Management is the body of knowledge on how to smoothly run short development iterations typical in agile development teams. Agile iteration management is largely driven by the Scrum practise. This is typically challenging when iteration cycles are of week duration and the code developed in the iteration is going into the live environment. An iteration's length should not be defined by time but by the team's output i.e. each iteration should deliver something of significant value to the customer otherwise the iteration is too short. However, the iteration's cycle time should at the same time be short enough so that the customer sees frequent updates in value adding functionality. This generates the buy-in that is lacking in so many IT projects. In many agile projects, the typical length of an iteration is 2-weeks and it is strongly encouraged that an iteration not exceed 4-weeks to ensure that the benefits of delivering to shorter cycles is realised.

This article will describe the standard ceremonies that make up an iteration, i.e., planning, retrospectives, showcases, and daily stand-ups. It will also describe very effective agile story walls, typical progress charts used, what are the performance metrics that count and more about planning and estimation.

This article is a part of the Agile Business Transformation article.

Definition of Common Terms

Daily Stand-up: A daily stand-up is used during the course of the iteration. It is 15 minutes where the team gets together to discuss what they accomplished since the team last met, what they plan to accomplish next, and if they are facing any impediments. It’s a great technique for raising awareness of team blockers.

Card Wall: A card wall displays the work, the user stories and/or tasks, that the team is working on in an iteration in a transparent and visible manner. The team talks to the card wall during their daily stand-up.

Retrospective: This is an important discussion with the team at the end of each iteration to discuss what has been working well and the areas for improvement. One of the agile principles is allowing the team to continually refine and improve from their learnings.

Showcase / Iteration Review: A showcase or sprint review is an opportunity for the team to show the business stakeholders the working software and to get two-way feedback to assess if the iteration goals have been met.

Burndown Chart: A burn-down chart is used to track the team’s progress during the iteration to understand the team’s capability. The primary metric used in a burndown chart is the remaining story points to be delivered in the iteration.

Typical Agile team composition A typical agile team is made up of an iteration manager, also known as scrum master, the team, and the product owner.

Iteration manager/Scrum master is the team facilitator. Compared to the traditional approach of a project manager who dictates what can be done, how it will be done, and when it needs to be done, an iteration manager facilitates the delivery of the work to be done. They also address team barriers/blockers and escalate blockers outside the team's control.

The Product owner is the key decision maker. Compared to the traditional approach of business stakeholders/SMEs, a product owner is a full-time core member of the team. The product owner understands the business vision, helps guide the team, and is the final authority for all requirements. The product owner determines whether a specific requirement has been successfully delivered or not.

The team exhibits certain characteristics. Some of the principles that the team follows are: - Self organising - Demonstrates self discipline and takes responsibility for delivering what they commit to - Can clearly articulate the business value that the project is delivering as well as the goals and drivers[[Category:]]

Wiki Contributors
Collapse Expand Close
  • Bsomich
    Article Score:15
    Total Score:4351
  • Mmuir
    Article Score:6
    Total Score:2
  • Jehrytt
    Article Score:3
    Total Score:4

View more contributors