For sure you have heard about Agile management, but do you know what a good Clojure plan looks like? What makes it agile? Keep on reading this book summary of Mike Cohn’s Agile Estimation and Planning which is reflected in the daily activities of Clojure developers in Flexiana.

The Goal

Agile planning is more about planning than creating by doing and activities in the whole process.

Estimating can never be one hundred percent precise, but it can be accurate, reliable, and trustworthy while planning for a project. Estimations can give a good insight into the risks, costs, and schedule of the project.

Estimating Size

In different projects estimating the size of different features is an important task. Also, there are ways to estimate user stories and features in every agile project. Estimation is about knowing whether a particular feature is larger or smaller than the other ones.

Story points are a unit of measure for the size of a user story, feature, or other parts of work to see the sie of the whole work. The number of story points related to a story shows the overall size of the story.

Ideal time is the time needed to meet user stories if there were no distractions, hindrances, etc. The amount of ideal time a developer has during a day varies depending on different factors including the company and environment.

Velocity is a measure of a team’s rate of progress per iteration. It is calculated by summing completed story points at the end of each iteration.

There three common techniques for estimating, which is better if not used solo:

1. Expert opinion: an expert can read the user story clarify some questions and estimate based on his intuition, which is not time-consuming
2. Analogy: The estimator compares the story with one or more other stories. 
3. Disaggregation: Split the story into smaller pieces which normally should happen to large stories and projects then start estimating.

A fun way is by playing planning poker, which includes all three techniques and requires all developers of the team. Basically, the steps are:

1. The Product owner explains a user story.
2. The team discusses that story.
3. Everyone put a card to show their individual estimation.
4. The estimation cards are revealed at the same time.
5. The team members with the lowest and highest estimations should justify their answers.
6. The team plays again until they come up with a unit estimation.
7. After some rounds, you can stop to see if everyone is happy and agree.

Don’t forget that if the relative size story points change, you should re-estimate.

Planning for Value

Prioritizing everything is for sure essential for every project, even in daily life. There are four factors to be considered at first:

1. The financial value of having the features. 

2. The cost of developing (and perhaps supporting) the new features. 

3. The amount and significance of learning and new knowledge created by developing the features. 

4. The amount of risk removed by developing the features.

Separate features into three categories:

1. Threshold or must-have features; which must be present in the product to make it successful.
2. Linear features; are the quantifiers that make customers happy as the better these features work, the more satisfied the customer will be.
3. Exciters and delighters; these features are not necessary, but they can be looked at as a premium option for ultra satisfaction.

Separate the functional and non-functional aspects of a large story into different stories. Don’t split a large story into tasks but try to find a way through the story itself. After splitting the story, don’t add extra work or adding changes to an appropriately sized feature unless the changes have equivalent priority. This way each feature can be delivered in two to five days, ideally.

Scheduling

Release planning contains user stories to create a high-level plan identifying the product owner’s satisfaction goals while iteration planning includes tasks estimated in story points for more detail.

“Release planning is trivial: Multiply the expected velocity by the number of planned iterations and then select stories whose estimates sum to fill up the release.”

Normally release plan is updated at the start of each iteration.

When planning an iteration, tasks are not given to certain members. It is better to promote “we’re all in this together”. 

There are bugs and defects. A bug is generally caused during development and found during testing. The bugs are then, sent back to be fixed. But a defect shows a wider problem normally with the specifications. If a defect is found it can be pretty costly to get fixed. A feedback loop can help with avoiding defects. 

The reason for iterations is to fix all the bugs that are discovered and to make sure conditions of satisfaction for the release can be met. 

The scheduling process consists of six steps:

1. Determine the conditions of satisfaction.

2. Estimate the user stories.

3. Select an iteration length.

4. Estimate velocity.

5. Prioritize user stories.

6. Select stories and release date.

All in all, iteration planning makes the structure, and release planning shows the direction!

Tracking and Communicating

Velocity measures the amount of completed work of the team each iteration. The team cannot use half-completed stories while counting velocity. The aim is to track progress toward the high-level goal of a release. Also tracking the development progress of a single iteration is helpful.

A good tool to track the iteration progress is task boards, where you can move every task done from one column to another.

Also, burndown charts are another good tool both for iteration and release plans. But teams should not calculate individual velocity in iterate tracking.

Do not forget that tracking should only at the team level and not at the individual members’ level.

Communication about estimates and plans should be frequent, with honesty, and two-way.

Teams can use Gantt charts while features that are shown, should be in process for the entire iteration duration. The goal of communication is to have feedback loops to learn more about the project to keep it moving toward a common goal. This way also uncertainties can be acknowledged and planned for.

A successful feedback loop keeps the project on track and on target.

Some Takeaways

• Activities don’t finish early.
• Lateness is passed down the schedule.
  • Coding of the middle tier finishes early, which is influenced by when adding tables to the database is finished. 
  • Coding of the user interface finishes early. 
  • The tester should be available early.
• Activities are not independent.
• Multitasking can cause further delays.
• Ignore uncertainty.
• There is no sequence of priority.
• Use velocity when forecasting
• An agile team works as one.
  • Product owner
  • Customer:  for internal use, the customer is usually a representative from another group or division. On such projects, the product owner and customer roles are often combined. The customer may or may not be a user.
  • Developer: even product owners can be developers as well in some projects
  • The project manager
• An agile team works in short iterations.
  • Iterations are timeboxed even if the functionality is dropped.
• An agile team should not be larger than 9 people.
• The release plan looks ahead for the duration of the release.
•  An iteration plan looks ahead only the duration of one iteration.
•  A daily plan is the result of team member commitments made to each other in a daily stand-up meeting.
• Understanding the product owner’s conditions of satisfaction is critical.
  • During the plannings, the product owner may need to relax one or more of her conditions of satisfaction.
• Communication is mandatory.
• Acknowledge uncertainties.
  • Re-planning reduces these uncertainties.
• The feedback loop keeps the project on track.

Here at Flexiana we believe in Agility and reflect these principles while working in iterations. If you like to know more about our delivery process please contact us.

Bibliography:

Agile Estimating and Planning 

Download for Reinventing Organizations

You can also get additional interesting information about this content. With our newsletter, you will get an efficient set of tools to learn a lot about topics focused on services & digital product building. Read more.