Agile Simulations

Agile is easy to understand but difficult to practice – These are the words from the founders of Scrum (The most popular among the agile frameworks). Why is it so?.

Agile has a very few ceremonies like the;

  • Iteration planning meeting
  • The iteration (Sprint)
  • Daily stand up meetings (Daily Scrum)
  • Iteration Reviews (Sprint Reviews)
  • End of Iteration retrospectives (Sprint retrospectives)

Within the small (10 member) agile teams we have only three roles;

  • Product owner
  • Scrum master (Agile Servant Leader)
  • Development team

Agile teams have only very few artifacts like;

  • Product backlog
  • Iteration(Sprint) backlog)
  • Tracking board (Kan-ban board)
  • Burn down charts
  • Product increment

It looks very simple and yet they say that it is very difficult to practice. Why is it so?.

Agile is principle driven, not just process driven. Anything that is principle driven is easy to read and understand, but difficult to practice, like the 10 commandments. True agility happens with a mindset change and that takes time. This fact of agile is the most difficult to explain through the online media. One has to experience it, to appreciate it.

The key objective of this dynamic blog post is to;

  • Explain how good agile projects work in real life through a sequence of scenarios
  • Help people prepare well for agile related certifications like new PMP, CSM, CSP etc where the assessments are based on real life scenarios.

Day#1

The Iteration or Sprint starts with the Iteration planning meeting. The output of the iteration planning meeting are;

  • The list of features to be developed during the iteration
  • Estimated story points (feature points) for the features (Fibonacci series)
  • The activities that need to be performed and their effort estimates
  • The tracking board (kanban board) which has the columns for;
    • To be done
    • Being done
    • Done
  • The Iteration / Sprint burn down chart
    • One with cumulative effort required to complete the sprint on the ‘Y’ axis and the duration of the sprint on the ‘X’ axis. The balance effort required to complete the sprint gets updated on a daily basis. This is a re-estimate by the team on a daily basis (this is not planned effort – consumed effort). This type of iteration burn down charts with the effort required to complete the iteration on the ‘Y’ axis and the iteration duration on the ‘X’ axis will help teams to speed up when required.
    • Teams use Iteration burn down to monitor the story points completed against the story points planned within the iteration. In this case the ‘Y’ axis will have the total story points planned for the sprint. This will get decreased based on the actual story points completed. This type of iteration burn down charts help the project stakeholders, especially the product owner to monitor and control the story points planned Vs achieved within the iteration.

Sprint burn down – Immediately after the planning meeting

Sprint burn down – After Day#1

This is the updated sprint burn down chart. After day#1, the ideal balance effort would be 950. Based on the revised estimate by the team, in-order to complete the balance work within the sprint, they need 970, which is reflected by the red line.

Is this a situation to worry and take corrective actions?. Not yet. This is the first day of the first iteration.

Sprint burn down – after day#2

This is the snapshot of the sprint burn down after day#2 of the sprint. The balance effort required to complete the balance work is lower than the anticipated balance effort after day 2. That means the team has completed more work than planned.

Sprint burn down after day#3

The re-estimated balance effort required to complete the sprint is going above the ideal line. These kind of fluctuations are normal during the early sprints. The good news is that after some time these fluctuations will reduce.

Sprint burn down on a Sunday

The status remains the same, as nobody has worked on the sprint on this week end (Saturday, Sunday). When we plan the sprint duration as 20 days, that is excluding all holidays. In fact, agile team members are not supposed to work more than 8 hours a day, because the sprint is planned with the assumption that people will work only for eight hours or seven hours / day and excludes all holidays. Only then agile teams can sustain productivity.

Sprint burn down chart after day#4

The effort required to complete the balance work within the sprint is again back to the ideal line. The team will be happy today as things are going as planned.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s