Agile planning, monotoring and adapting
Agile planning, monotoring and adapting
– Acceptance criteria
– Burn-down chart
– Burn-up chart
– Cumulative flow diagrams
– Definition of Done
– Iteration
– Kanban boards
– Lean manufacturing, lean-agile software development
– Process tailoring
– Reflection
– Reflexive improvement workshops
– Release planning
– Rolling wave plan or rolling look ahead plan
– Stakeholders
– Time boxing
– User Story
– WIP limits
Acceptance criteria
Acceptance criteria is typically defined in tandem with user story definition during release planning; however, acceptance criteria can also be defined during iteration planning once a story has been picked for the iteration. The one steadfast rule is that acceptance criteria must be defined before development begins. Like agile planning, the definition of acceptance criteria is constantly evolving as the conversation with the product owner matures. [The Art of Agile Development. James Shore.]
During release planning, acceptance criteria are typically recorded on the backs of user story cards. Agile team testers will use this acceptance criteria in their verification tests. [The Art of Agile Development. James Shore.]
Acceptance test criteria should be written at the last responsible moment, this is not the right time for writing them. While velocity, product backlog and release length are essential input for release planning.
The acceptance criteria doesn’t be too vague (remember the T of INVEST for defining good user stories) and cannot be easily tested. [The Art of Agile Development. James Shore.]
Burn-down chart
A burndown chart is a plot of work remaining to reach a given goal on the vertical axis, and time on the horizontal axis. Each point on the chart shows how much work was left to do at the end of that day (or week, month or other time period). Regular review of progress charts such as burndown charts or burn up charts for the project you are managing can immediately identify problems and allow you to control them early. Identifying problems early and highlighting corrective action you have taken will impress your clients and gain you their confidence and trust.
To read a burndown chart imagine an « ideal » line running diagonally from the top left to the bottom right corner. Some burndown chart may actually have this line indicated on the chart. The ideal line represents the required burndown to reach the goal, or the ideal position to be in at the end of each day. The actual burndown line can be compared against this line to provide a simple measure of the progress of the project. If the actual line is above the ideal line the project is behind schedule. If the actual line is below the ideal line the project is ahead of schedule. The distance above or below the line shows how much the project is ahead or behind.
The amount of work remaining in a burndown chart is typically estimated by the number of tasks remaining to be completed. This is due to simplicity and the smaller amount of volatility in the numbers compared to time estimates associated with the tasks.
Burndown charts are an important visual informational tool used by effective project managers. Burndown charts are particularly common in the agile and scrum project management methodology, where they are often used to understand and track the progress of a development sprint or release.
– Why use a burn-down chart ?
The popularity of burndown charts stems from their simplicity. It is a simple concept to see that the number of tasks must reach zero by a defined date. The human visual system also makes it very easy to extrapolate a trend from the data and see whether the goal will be reached in time or not. Thus burndown charts are useful aids to explain and demonstrate the progress of a project to anyone, regardless of whether they match your level of experience in project management. Therefore it is often a good idea to creating a burn down chart for use in presentations and demonstrations to clients and non-technical management.
Some managers also consider burndown charts to have a motivational value. Seeing the line creep ever closer to zero will encourage and motivate project participants, and clearly demonstrate that progress is being made. Personally, I believe that other charts of project progress such as burn up charts have the same motivational power, and so motivation should not be used as a reason for choosing a burndown chart over a different progress chart.
In summary, consider making a burndown chart if simplicity is your most important communication goal, and simplicity overrides the problems with a burndown chart.
– How to create a burn-down chart ?
Burn down charts are easy to create manually using pen and paper, or they can be created by entering the data into a spreadsheet program such as excel. Alternatively software tools such as Intelligent Reports make it trivially easy to create a burndown chart for your project by using data already contained in your project management system. There is no excuse for not making a burndown chart on a regular basis to review the progress of your project.
Burn-up chart
A burn up chart, or burnup chart, tracks progress towards a projects completion.
In the simplest form of burn up chart there are two lines on the chart:
– A total work line (the project scope line)
– A work completed line
The vertical axis is amount of work, and is measured in units customized to your own project. Some common units are number of tasks, estimated hours or story points (in agile project management methodologies).
The horizontal axis is time, usually measured in days.
At each day you can see the amount of work completed and the total amount of work. The distance between the two lines is thus the amount of work remaining. When the two lines meet, the project will be complete. This is a powerful measure of how close you are to completion of the project, similar to a burn down chart.
The advantage of a burn up chart over a burn down chart is the inclusion of the scope line. It clearly tracks when work has been added to or removed from the project. It also allows you to visualize a more realistic completion date for the project, by extending a trend line from the scope as well as the completion line. Where the two trend lines meet is the estimated time of completion.
The scope line allows you as a manager to easily spot where work is being added which will affect the completion date. Whether this work is being added by the client or the team, it is an important signal that the completion date may need to be moved in response. The scope line also tracks where work is being removed to meet a fixed deadline. Again this is important to know as it may impact the quality or functionality of the project, and is something that needs to be clearly discussed with the client and team.
Although a typical burn up chart only has two lines, other lines are sometimes included. Firstly an ‘ideal’ line may be included. This shows the completion necessary at each day to meet the deadline. You can then tell if the project is ahead of or behind schedule by whether it is above or below the ideal line, and the distance gives you an idea as to how far ahead or behind schedule it is. (The ideal line is usually based on the most recent available total scope for simplicity)
Another line that is sometimes included is the required burn up line. This line shows how much work must be completed to meet the deadline, given the current scope.
Lastly, several burn up charts can be superimposed on top of one another. This is typically done for multi stage projects, such as release versions or development sprints in a software project. The scope lines are cumulatively stacked, whilst the completed line is either combined for all releases, or only for the next release and previously completed releases on any given day. The advantage of this layout is that it is clear when work is being shifted from one sprint to the next, as opposed to being added to the total project scope.
More advanced, but also more complicated to read than a burn up chart is a cumulative flow diagram.
– Why use a burn-up chart ?
The goal of any chart is communication, a burn up chart clearly shows work completed and project scope. It is an effective tool for communicating to the project stakeholders and clients how the extra feature requests they are asking for will affect the deadline, and at the same time for reassuring them that good progress is being made. In a project where clients are adding a lot of work mid-project, a burndown chart will not be an accurate reflection of the project teams output, and could lead to performance questions from the client. A burn up chart can quickly make clients re-evaluate whether they really need that extra bell or whistle.
Unfortunately burn up charts are slightly more complex to interpret than burn down charts, so will often require some short explanation to people not familiar with them. However because of the extra information represented in a burn up chart, this explanation is usually more than worth the time, with the possible exception of large group situations.
– How to create a burn-up chart ?
A burn up chart can be created with many tools, from pen and paper to a spreadsheet program such as excel. The easiest way to create a burn up chart tracking a particular project is to use a project management tool with a good reporting system, such as Intelligent Reports for JIRA. Using reporting tools, burn up charts can be instantly or even automatically created using the data already tracked in your project management system. There is no excuse for not regularly reviewing progress charts such as burn up charts or burn down charts to check on the progress of your project, and take corrective action if any problems are discovered.
Burn-up vs burn-down chart
– Overview
Burn down and burn up charts are two types of charts that project managers use to track and communicate the progress of their projects. A burn down chart shows how much work is remaining to be done in the project, whereas a burn up chart shows how much work has been completed, and the total amount of work. These charts are particularly widely used in Agile and scrum software project management.
– Your goal ?
The primary determinant in whether to use a burn up or burn down chart is what you are trying to accomplish, your goal. Are you presenting to clients for the continued survival of the project? Are you trying to motivate your project team? Are you simply trying to increase your own knowledge and understanding of what is happening in the project? The answers to these questions will determine which chart to use.
– Simplicity vs information
Burn down charts are simple. A single line racing towards zero as the project is completed. Anyone can understand this chart, and it does not need an explanation. However it can hide important information, for example the effects of scope change.
Scope change is when work is added to or removed from a project. We are all familiar with scope change, the client suddenly demands extra features, or work is removed from a project to meet a deadline. A burndown chart does not show this information as clearly as a burn up chart.
A burn up chart tracks completed work and total work with two separate lines, unlike a burn down chart which combines them into a single line. The total work line communicates important information – is the project not yet complete because work is slow to be done, or too much new work is being added. This information can be crucial in diagnosing and rectifying problems with a project.
– Presenting project progress on a regular basis
If you are presenting project progress to the same audience on a regular basis, for example weekly customer progress meetings, you are probably better off with a burn up chart. It will allow you to easily show them you are making progress, even if they have been adding more work, or testing has revealed problems that are adding work to the project.
– Convincing customers to stabilize project scope
Scope creep is the enemy of every software project. In the face of scope creep burn down charts start to look like little progress is being made. However a burn up chart clearly makes the scope creep problem visible to the customer. This may even help you to convince them to stop requesting changes and allow the project to complete.
– Fixed scope projects
There are certain limited circumstances in which a project may have a well defined fixed scope. If a project is guaranteed to have fixed scope, the burn up chart communicates no more information than a burn down chart, so the simplicity of the burn down chart is preferable.
Cumulative flow diagrams
Like burnup charts, cumulative flow diagrams are information radiators that can track progress for agile projects. CFDs differ from traditional burnup charts because they convey total scope (not started, started, completed) of the entire backlog. Tracked items can be features, stories, tasks, or use cases. By tracking total scope, CFDs communicate absolute progress and give a proportional sense of project progress (e.g., On Day 14: 15% of features have been completed; 15% have been started; and, 70% have not been started). [Lean-Agile Software Development: Achieving Enterprise Agility. Alan Shalloway, Guy Beaver, James R. Trott.]
A diagram used by Kanban is the cumulative flow diagram (CFD), which describes the overall flow through the Kanban system; it provides a measurement for every significant step in the workflow.
Definition of Done
The ‘done’ column holds tasks that have been completely developed, tested or verified, and integrated into the product and require no further attention. The ‘done’ column should not hold incomplete tasks, but ones that are truly completed. [Lean-Agile Software Development: Achieving Enterprise Agility. Alan Shalloway, Guy Beaver, James R. Trott.]
Definition of Done, the team makes it into congruence with the Product Owner, and definition of done is used to keep the meaning of ‘done’ consistent and unambiguous to all.
Iteration
– Change report
A change report is typically authored after a sprint has completed. [Agile Project Management with Scrum. Ken Schwaber.]
– Iteration planning
Iteration planning occurs before every iteration [The Art of Agile Development. James Shore.]
When a team performs iteration planning, it prioritizes features or user stories to develop in the forthcoming iteration by priority and velocity. The most valuable user stories are typically developed first and the team’s estimated velocity helps plan how many user stories or features should be developed in the iteration. [The Art of Agile Development. James Shore.]
When defining the length of iterations, the team should consider how it will deliver valuable chunks of product functionality, the definition and development of user stories, and the acceptance of user stories by customers. [Agile Estimating and Planning. Mike Cohn.]
During iteration planning, the team follows three steps to create an iteration backlog: 1) The team decomposes large or complex user stories into multiple, smaller stories, 2) The team breaks each user story into development tasks, and 3) The team estimates the task effort or duration, typically using ideal hours. [The Art of Agile Development. James Shore.]
– Iteration backlog
An agile team creates the iteration backlog during iteration planning [The Art of Agile Development. James Shore.]
– Iteration review
Iteration review is a step where stakeholders look at the progress by looking at working software.
– Progress
Tasks board : an agile team often uses a task board to monitor and control progress. A task board identifies tasks to be completed during an iteration and their progress. [Lean-Agile Software Development: Achieving Enterprise Agility. Alan Shalloway, Guy Beaver, James R. Trott.]
– In Progress column
As a developer on the agile team, Greg is beginning development on a task. Greg is at the task board and must place the task card in the correct column of the task board to update everyone of its status. reg should place the task card in the ‘in progress’ column to signify that the task is currently being executed. [Lean-Agile Software Development: Achieving Enterprise Agility. Alan Shalloway, Guy Beaver, James R. Trott.]
– Review
Because the product owner is responsible for ROI and has the most knowledge on what the complete objectives are for a product, the product owner should lead the sprint review. [Agile Project Management with Scrum. Ken Schwaber.]
– Tasks
The acronym SMART (specific, measurable, achievable, relevant, and time-boxed) helps the agile practitioner remember the characteristics of a well-defined task. S – Specific tasks are ones that clearly contribute to the development of a user story. It should not be vague. M – Measurable tasks are ones that the team and customer can verify. A – Achievable tasks are ones that developers may realistically implement and understand. R – Relevant tasks are ones that unequivocally add value to the user story. T – Timeboxed tasks are ones that can have an estimate assigned of the amount of effort or time needed for development. [Agile Retrospectives: Making Good Teams Great. Esther Derby, Diana Larsen, Ken Schwaber.]
S – Specific tasks are ones that clearly contribute to the development of a user story. It should not be vague.
M – Measurable tasks are ones that the team and customer can verify.
A – Achievable tasks are ones that developers may realistically implement and understand.
R – Relevant tasks are ones that unequivocally add value to the user story.
T – Timeboxed tasks are ones that can have an estimate assigned of the amount of effort or time needed for development.
Agile team members should feel free to update incorrect task time estimates as soon as possible. Team members can use current iteration progress and accrued experience to come to a new task time estimate. [Lean-Agile Software Development: Achieving Enterprise Agility. Alan Shalloway, Guy Beaver, James R. Trott.]
Kanban boards
Kanban, Japanese for billboard or signboard, is a scheduling system for just-in-time (JIT) production developed by Toyota in the 1940s and 1950s. It is a way of controlling and reducing inventory by using cards or signs to order (demand signal) requisite parts for a manufacturing process from other dependent systems (supply). Kanban has been adopted by agile to help control workflow. [Lean-Agile Software Development: Achieving Enterprise Agility. Alan Shalloway, Guy Beaver, James R. Trott.]
Kanban is a just-in-time (JIT) scheduling system for inventory control. Production processes only execute if there is a demand signal for the part being processed. Carefully controlling inventory in this manner ensures that no machine is producing unnecessary/unordered parts. A machine will only send a demand signal if it has the capacity to perform the manufacturing immediately. Therefore, inventory (or WIP) will not backup or bottleneck at machines because the demand signal for inventory is highly controlled and based on processing speeds and absolute need. [Lean-Agile Software Development: Achieving Enterprise Agility. Alan Shalloway, Guy Beaver, James R. Trott.]
Lean manufacturing, lean-agile software development
– Columns
All tasks must go through a testing or verification process to ensure quality is built into the development process. Typically, completed tasks are moved to the ‘Ready for testing’ column. Testing is then executed by the project testers and the customer. It is important to note that some tasks on the task board will not have specific verification or testing criteria. These tasks don’t go in the ‘Ready for testing’ column but still need to be verified and are often placed in a ‘To verify’ column. [Lean-Agile Software Development: Achieving Enterprise Agility. Alan Shalloway, Guy Beaver, James R. Trott.] [Planning, monitoring, and adapting]
– To do
Tasks that have not yet started should be located in the ‘to do’ column. [Lean-Agile Software Development: Achieving Enterprise Agility. Alan Shalloway, Guy Beaver, James R. Trott.]
– In progress
– Ready for testing
Typically, completed tasks are moved to the ‘Ready for testing’ column. Testing is then executed by the project testers and the customer.
– To verify
It is important to note that some tasks on the task board will not have specific verification or testing criteria. These tasks don’t go in the ‘Ready for testing’ column but still need to be verified and are often placed in a ‘To verify’ column. [Lean-Agile Software Development: Achieving Enterprise Agility. Alan Shalloway, Guy Beaver, James R. Trott.]
– Done
– WIP
Work in process = WIP
A lean manufacturing philosophy is to eliminate waste. One defined waste type in the lean philosophy is inventory, which is also referred to as work in process (WIP). WIP is material or parts that have started production but are not yet a finished or « done » product. Inventory is considered wasteful because it costs money to purchase, store, and maintain. One way of reducing inventory is to reduce the WIP at individual machines or servers by only moving as fast as your slowest machine or processor (the system bottleneck). Agile also strives to control its WIP through WIP limits by completing all features to a « done » state before beginning development of new features. One can think of an iteration or sprint as a process that can develop a certain amount of features. In this analogy, the WIP limit is equivalent to the sprint backlog. By maintaining a WIP limit equal to the sprint backlog, no features should be incomplete at the sprint review. [Lean-Agile Software Development: Achieving Enterprise Agility. Alan Shalloway, Guy Beaver, James R. Trott.]
Like lean, agile efforts try to reduce WIP to a manageable and sustainable level. [Lean-Agile Software Development: Achieving Enterprise Agility. Alan Shalloway, Guy Beaver, James R. Trott.]
– WIP limit
A limit of how many WIPs can be in process at one time.
Process tailoring
Project trade-off matrix : the project trade-off matrix classifies the constraints of scope, schedule, and cost as fixed, flexible, or accept. [Agile Project Management: Creating Innovative Products – 2nd Edition. Jim Highsmith.]
Reflection
During reflection an agile team takes a break after completing an iteration to pause and contemplate about its performance. Topics include: lessons learned from successes and failures, such as programming methods that were highly efficient or inefficient; how to reinforce successful practices, such as new testing standard practices; how to discourage negative practices, like straying from team approved coding standards in order to make an iteration deadline. [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]
Sprint retrospective are reflexive improvement workshops :
Reflective improvement workshops are a cornerstone of the Crystal methodology. While all agile methodologies incorporate reflection into their standard practices, Crystal terms the practice ‘reflective improvement workshops.’ [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]
Setting the stage for a retrospective means creating a safe environment that is open and honest. [Agile Retrospectives: Making Good Teams Great. Esther Derby, Diana Larsen, Ken Schwaber.]
Release planning
– Blitz planning
Blitz planning incorporates story dependencies and involves using cards to plan a project where timeline, tasks, and story dependencies are identified and considered. [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]
– Parking lot
An agile practitioner can use the project parking lot and story card layout to summarize a release plan. [Agile Estimating and Planning. Mike Cohn.]
– Release planning
Release planning helps the customer and agile team determine what should be developed during each project timeframe or phase, and when a product will ideally be ready for release. [The Art of Agile Development. James Shore.]
Planning for a release occurs during release planning. [The Art of Agile Development. James Shore.]
In release planning, the agile project manager discusses the product vision with the development team in detail. This ensures that the proper requirements, acceptance criteria, and priorities are established. [The Art of Agile Development. James Shore.]
For new product development projects, it’s good to plan at least 5 adaption points in a release, we analyze the performance at the end of iteration so we should have some minimum number of iterations which helps us in adapting based on the discovery we make at iteration end.
– User stories or features
User stories or features are first assigned to iterations during release planning. The user stories are features are then decomposed into tasks during iteration planning so that the tasks may be assigned to specific developers. To help manage planning and monitoring, a rule of thumb for estimating task duration is that each task should take approximately four hours to two days of development work. [The Art of Agile Development. James Shore.]
– Velocity
The team uses its velocity to pick the number of user stories to develop in the upcoming iteration. [The Art of Agile Development. James Shore.]
We calculate cost and time budget at release level based on estimated size and velocity. Product Owner is the one who owns the release plan.
Rolling wave plan or rolling look ahead plan
When using a rolling wave or rolling look ahead plan for complex projects, only work that is about to be completed for the next few iterations – where requirement details are better understood – are planned. The plan includes all interdependent agile project teams to ensure successful integration of tasks. [Agile Estimating and Planning. Mike Cohn.]
In large, complex projects, agile project leaders can facilitate iteration planning by using a rolling wave or rolling look ahead plan, which involves making plans for the next few iterations at a time. [Agile Estimating and Planning. Mike Cohn.]
Stakeholders
Stakeholders are a critical component of the agile framework where the latest increment of product functionality is demonstrated to the stakeholders for inspection, feedback, and adapting. [Agile Estimating and Planning. Mike Cohn.]
Time boxing
Timeboxing is a realistic estimate or expectation of how long an action, task, or event will take to perform. Some tasks cannot be performed in the initial timeboxed estimate and are good candidates for reevaluation and possibly further decomposition into more tasks. [The Art of Agile Development. James Shore.]
– Avantages
Establishes a WIP Limit
Forces Prioritization
Demonstrates Progress
– Scrum
In the agile framework scrum, sprint planning and sprint review meetings are often timeboxed at four hours. [The Art of Agile Development. James Shore.]
– Sprint planning, sprint review, sprint retrospective
4 hours
User Story
User stories are prioritized based on customer value. Value is determined by return on investment, growth of team knowledge, and risk reduction. [The Art of Agile Development. James Shore.]
The team should meet with the customer to determine if and when the user story should be completed. [Agile Estimating and Planning. Mike Cohn.]
– 3 C
Ron Jeffries’ three Cs for user story definition are card, conversation, confirmation. [User Stories Applied: For Agile Software Development. Mike Cohn.]
– INVEST
Independent, negotiable, valuable, estimable, small, and testable
The acronym INVEST (independent, negotiable, valuable, estimable, small, and testable) helps the agile practitioner remember the characteristics of a good user story. I – Independent stories can be developed in any order and avoid dependencies which can make development more complex. N – Negotiable user stories mean that both the customer and developer should feel free to analyze and adapt a user story to meet customer needs. V – A valuable user story describes how the product feature will provide value to the customer. E – Estimable user stories are ones that developers can readily estimate the effort or duration required for developing them. S- Small user stories are ones that take about two to five days of work to implement. T – Testable user stories are ones that can be verified according to acceptance criteria to ensure value. [Agile Retrospectives: Making Good Teams Great. Esther Derby, Diana Larsen, Ken Schwaber.]
I – Independent stories can be developed in any order and avoid dependencies which can make development more complex.
N – Negotiable user stories mean that both the customer and developer should feel free to analyze and adapt a user story to meet customer needs.
V – A valuable user story describes how the product feature will provide value to the customer.
E – Estimable user stories are ones that developers can readily estimate the effort or duration required for developing them.
S- Small user stories are ones that take about two to five days of work to implement.
T – Testable user stories are ones that can be verified according to acceptance criteria to ensure value.
– If a team has a velocity of 20 story points and there are 83 story points remaining in the backlog and excluding all other potential constraints like increased scope, how many iterations should it take for the project team to complete the remaining story points?
3/20=4.15. Round 4.15 up to 5. 5 iterations is the best answer. [Agile Estimating and Planning. Mike Cohn.]
– Story points
In general, story points can be considered as the cost of developing a user story, while value points can be considered as the benefit of developing a user story. [Agile Estimating and Planning. Mike Cohn.]
A 0 point user story is said to be of minimal effort for a development team. [Agile Estimating and Planning. Mike Cohn.]
WIP limits
– Work in process
A Kanban board shows work in process (WIP), which represents work started but not completed. Therefore, the WIP should be limited and carefully managed to maximize performance. More WIP does not equal more output; in fact, it is quite often the opposite. Also, WIP is any work that is in progress, regardless of what stage the work is at, so the answer options that limit it to work waiting for quality assurance or user acceptance are wrong.
Like lean, agile efforts try to reduce WIP to a manageable and sustainable level. [Lean-Agile Software Development: Achieving Enterprise Agility. Alan Shalloway, Guy Beaver, James R. Trott.]
Leave a Reply
You must be logged in to post a comment.