An adaptive planning and monitoring approach acknowledges that planning is an ongoing process and the following tools help to pro-actively update the plan. This is one of the biggest difference between traditional static planning to Agile adaptive planning.
Agile Reviews
Reviews are usually done by experts from outside the team. Their opinions are usually important and should be followed, or at least considered, by the team.
At a certain level, reviews from outside the Agile team can impact the level of “pure” self-organization, since review brings in more people who can evaluate the product increment from different viewpoints. But will a review really break the agility and self-organization of the team? I believe not.
Reviews are needed for different reasons. If they’re not needed or aren’t beneficial to the organisation, of course, they should be reduced or removed from the life cycle. But let’s imagine here that they are needed and useful. We can take it as an internal requirement that should be weighed, just like the external customer requirement. If we can use self-organization to meet external customer requirements well, we can use it to meet such internal requirements as reviews.
>> More Info on How to Make Agile Reviews More Effective
Kanban/Task Board
A Kanban board is a tool used to visualise the workflow that enables the team to optimise the flow of work. A typical Kanban board will use sticky notes and have at least 3 columns where the far left is the backlog, middle in progress and far right is the done column. It easily communicates the work status of tickets.
>> Slideshare deck on How Kanban and Scrum can be used in an Enterprise
Time-boxing
Time-boxing is limiting the time spent on an activity. A spike is a time-boxed activity to do research or investigate an “unknown”. The daily stand-up is time-boxed to 15 minutes. The retrospective is time-boxed to 2 hours.
WIP Limits
Work In Progress limits is used to limit the amount of stories allowed in each column on a Kanban board. WIP limits are a strategy for detecting preventing bottlenecks. The WIP limits are agreed by the team before a project starts and enforced by the team facilitator. When a WIP limit has been hit for a certain task the team stops and works together to clear the bottleneck. John Little created Little’s Law a mathematical formula based on queueing theory that can be used to analyse work queues on Cumulative Flow Diagram. The formula proves that the duration of work queue is dependent on its size which is why WIP Limits are so important.
>> More info on setting WIP by the Agile Director
Iteration & Release Planning
Release planning is done before any iteration planning. The release is planned for a meeting where all stakeholders are represented to ensure their priorities are clearly expressed. The goal is to determine which stories will be delivered in the next release. During release planning the following will occur:
- Assess the prioritised backlog and the estimates on stories.
- Sort the stories by release.
- Refine the roadmap for the upcoming release.
At the end of the meeting, there will be a clear understanding of the release goal and what stories are to delivered within the release. The iteration planning then is done by the development team, the product owner and other stakeholders/subject matter experts as needed. Compared to the release planning iteration planning is a lot more detail and estimates will be a lot more accurate. The customer’s role will be limited to answering questions for the development team. The Product Owner will start the meeting by describing what they want in the iteration. The development team then commit to what they think is achievable in the iteration. Always remember:
- The Product Owner has the final say on the priorities for the iteration
- The Development Team has the final say on the amount of work to be done in an iteration.
The iteration planning process will follow this process:
- Discuss user stories in backlog
- Select user stories for backlog
- Define acceptance criteria and write acceptance tests
- Break down user stories into tasks
- Estimate the tasks.
>> More Information Iteration Planning by Version One
Variance Analysis
Variance analysis is used to identify the difference between expected and actual performance. Variance measures how far apart things are and how much they vary. Some variance is expected but it should be within acceptable limits, even highly engineered processes take into account some degree of normal variation due to normal fluctuation. Edward Deeming defined two types of variation:
- Common Causes: These are issues that are day-to-day differences to doing work.
- Special Causes: These are are issues that cause greater variance by a one-off or special cause.
Deeming determined it is a classic mistake where managers misinterpret common cause for a special cause and vice a verse.
>> More Info on Variance Analysis
Trend Analysis
Trend analysis collects data and analyzes them to detect patterns that may predict the future trajectory of the data. It is a very important tool for detecting problems as it provides insights into issue’s before they occur. Trend metrics are leading metrics as they provide an insight into what is happening now or in the future. Lagging metrics are metrics such as budget consumed which are based on the past.
>> More Info on Trend Analysis
Daily Stand Ups (DSU)
The daily stand-up is a time-boxed 15-minute meeting held by the team Agile team every morning. Each team member will keep their update at a high level and should answer the following three questions:
- What they did since last time they talked.
- What they plan on doing before the next meeting.
- Are there are impediments or blockers preventing them from moving forward.
Only team members will talk not the product owner or any other stakeholders. The product owner can answer the team’s questions and the Scrum Master/Team Leader will be responsible for removing impediments. To further understand why only the team members only talk check out the below cartoon about the pig and chicken. In simple terms, if the pig and chicken open a breakfast restaurant together selling bacon and eggs, the pig (team) will have it all to lose and the chicken (business) will only be involved.
>> More info on DSU from Agile Pain Relief
Burn Down
The burn-down demonstrates work remaining, the burn-up demonstrates work completed. As the burn-down chart is used to demonstrate the remaining work for a given period of time, it helps provide a quick update if the project is on track to hit its target. You can have a burndown chart for sprints and releases.
>> Really good article on Anti-patterns of Burndown Charts
Burn Up Charts
The burn-up chart shows how work has been completed and the total amount of work. One key difference between both charts is that the burn-up visibly demonstrates added/removed scope better than burn down charts.
>> More info on Burn Up Charts
Cumulative Flow Diagrams
A Cumulative Flow Diagram (CFD) is an area chart that shows the various statuses of work items for a particular time interval. The horizontal x-axis in a CFD indicates time, and the vertical y-axis indicates cards (issues). Each coloured area of the chart equates to a workflow status.
>> More info on Cumulative Flow Diagrams by the Agile Sherpa
Backlog Grooming/Refinement
This is the process of making sure the backlog is prioritised. It is the Product Owners responsibility to ensure the backlog is refined correctly. The backlog stories are prioritised from the top down, so the team will know to choose the story on top of the backlog to work on next. Backlog grooming should be done before estimation sessions so the correct stories are estimated and selected for the next iteration.
>> Cheatsheet on Backlog Refinement
Product-Feedback Loop
Product feedback is a core practice in Agile that every Agile methodology follows. Agile is all about delivering in frequent increments to gather feedback and adapt according to this feedback. The stakeholders are given demonstrations after iterations so they can review the product and provide feedback.
Control Limits
Control limits are a technique where you can set upper and lower limits to determine acceptable variation. A useful method of control limits is setting an upper and lower limit of user stories completed per iteration.
>> More info on Control Limits in Agile
Pomodoro Technique
Pomodoro Technique is lean concept based on individual time management similar to plan-do-check-act but scaled down for one person. The only tools you need are a kitchen timer, three sheets of paper and a pencil.
> The lean magazine did a great article on Pomodoro technique in Scrum