The agile roadmap is often confused with product roadmap or scrum ceremonies. The agile roadmap is indeed much beyond that. If it is not just the scrum activities then the question arises in terms of what is agile roadmap all about? How important is it to know what happens before sprint planning? For most of us, sprint planning is the beginning of agile project while it is not (Practically it can be considered as mid-stage). A lot happen before ‘sprint’ ceremonies. The agile roadmap would probably answer the entire process that is being followed to accomplish the project.

At a very abstract level, the agile roadmap has 7 phases listed as below:-

Vision

Product Owners in conjunction with senior leadership identifies the product vision.

The product vision talks about – What your product is, and what it entails? How it would support your company or organization strategy and who is going to consume it.

There are many more factors being considered here including the market, complexity, feasibility etc. Typically in this phase there is little or no involvement for the core development team.

Best practices

Touch base with your management and be updated with the vision of the product.

Provide inputs whenever applicable.

Product Roadmap

This phase defines high level of product requirements which are written at high level (EPICs).

Typically the EPICs are elaboration to have clarity while the stories may or may not be written.

The prioritization of EPICs happen as well in this phase.

The discussion between product owner and other stakeholders enable PO to define High level estimates (Probably ROM -> +/- 30%). Priorities



Best practices

Try to get involved in roadmap discussions.

Stay in touch with product management and ensure you know whats coming. What the organization goal is and what can we do to ensure we meet it.

Provide as much inputs as possible to product management to ensure the EPICs are well elaborated and understood.

Release Planning

The EPICs are further broken down into individual stories.

An agile project will have multiple releases with the highest priority features being picked up in order.

During this phase release timing for the specific product is determined.

The release plan must have to be created at the beginning of the project.

The number of sprints, team staffing and capacity is being looked at as well.

The estimation here is going to be +/- 10%. This is very important as the exact cost/schedule of the product/project is determined at the phase.

Best Practices

Every agile team must put in efforts to get involved in this phase. The solid understanding in this phase is core to success of the product/project.

Identify impediments and provide inputs for estimation.

Sprint Planning/Grooming

The sprint team works with PO to groom the requirements based on priority.

Technical and product dependencies are discussed.

Individual tasks are created for each requirement. The next level of estimates are created (+/- 20%). Planning poker, relative estimate, and WBD are quite commonly used to provide an estimation. Based on the maturity or project and organization in the specific area, complexity based estimation can be utilized as well.

The team gives commitment by looking at the capacity and next level of estimates.

Please click here to get more details

Best practices

If the requirements are clearly stated or acceptance criteria is not written ask PO to do the same.

The grooming should be a constant activity and should be done for most of the stories prior to sprint start date.

The goal of the planning is to ensure everyone is aligned with details for each story, estimation and sprint commitment. The planning can be done a day before sprint start date or on sprint start date.

The sprint commitment, assumptions and high level discussions should be sent to whole team.

The previous sprint must be closed before the next sprint start date. In addition to that the summary of the previous sprint to be sent to all the team members.

There should be a goal of N+2 sprint readiness which is to ensure that 2 sprint worth of work is groomed in advanced.

Make use of capacity planner for sprint commitment.

Daily Stand-ups

It should get completed in less than 10 minutes.

This meeting should answer What did you do yesterday? What are you going to do today? Any impediment? If yes, then what is that?

Please note that standup meetings are not planning or technical discussion meetings. These are neither meant for micromanagement nor a meeting to provide a status.

Please click here to get more details

Best Practices

The standup should be time-bound. It should get completed in 10 minutes for less for 10 member team.

Any design or technical discussion should happen post standup. Not everyone needs to participate unless absolute necessary.

The standup should happen in morning. If there is a dependency with onshore counterpart, it should happen twice in a day.

Sprint Demo

This is essentially the demonstration of the working product (or “showcase”). This should happen post QA or peer testing.

Please click here to get more details

Best practices

This is a continuous activity and should be done as and when the story is done-done.

No story should be mark done without a demo. In case if the PO is not available, you should give the demo to rest of the team, record the session and share with a PO.

Retrospective

This happens at the end of the sprint. All the stakeholders sit together and discuss Things which worked well Areas for Improvement or things which we should stop doing it Action Items

This meeting should also look at the action items of the previous retrospective and see where we stand. If the previous action items are not addressed, those should be included in current retrospective.

Please click here to get more details

Best practices

The retro must happen after every sprint. The retro should begin with action items of previous sprint.

There should be owner for each action item.

Be open. Appreciate people and discuss areas of improvement/things which did not work.

Many times the first three phases are ignored by agile teams. The ultimate success requires or expects that the entire agile team to be well versed with first 3 phases as well. They should be part of it from day one.

Common best practices

Be open and honest. Support team work over individual contribution.

More the co-location better the outcome. Avoid working from home and silos.

Constantly review burn down chart to see where we stand.

Pick approx. 20% of tech debt in every sprint.

Focus on continuous improvement. That’s good for a company and for your growth.

Go to with pair programming wherever there is a possibility.