1st way of planning

Agile is the methodology used for the projects where your scope is not known from the beginning. Requirements are not well defined, environment is changing a lot, they will keep continue to change, we cannot determine the exact work from the beginning. We have to adapt to changes, because business environment changes. 

In agile we have 3 ways of planning:

1. High-level plan - Product roadmap. Roadmap simply will show what features will be completed at the end of each release. We have releases and at the end of the release we will deliver features. Most of the time over a year we will have no more that 2 releases (3 is not recommended).

Roadmap will show you initial, high-level scope. What product we want to create at the end. Lets see what features are we going to deliver at the end of each release.

Lets assume that features ABC we are going to deliver at the first release and DEF we are going to deliver at the second release.

Features are equivalent to deliverables in predictive life cycle. Features that must be delivered at the end of the first release we call it Minimum Marketable Features, or Minimum Viable Products, must have and should have features - otherwise product will not be working. It will be minimum features but doesnt represent the entire product.

And those features you are going to implement in the first release are not going to change. So lets imagine A - Product list, B - shopping card, C - payment option. With these 3 features my website is going to work.

Lets imagine that D - filtering option, E - demonstration of the product, F - refer to friend features. These are the features I am planning to deliver at the end of the second release. But these features might change. If we will keep these features stable it means that we are doing a traditional life cycle. Maybe these features remain the same, but requirements inside the features will change. So second release is the subject of changes. 

The purpose of the roadmap planning is to see what features will be available at the end of each release. It will show how product will grow. Roadmap will not show how they will be develop, what should be delivered at the end of each release. 

This is high-level scope. Also here you can plan high level cost and schedule. Scope, schedule and cost will progressively refine as we go to the second and third level of agile planning. They will become more accurate, more detailed. 

In agile we dont calculate schedule in days - it called sizing and based on the size we will plan the work. If you cannot give the size you cannot estimate, if you cannot estimate you cannot plan the work.

In agile we have two types of size. The first one is called T-shirt size (XS, S, M, L, XL, XXL, XXXL). First we have to estimate the size of each feature with the t-shirt sizes. We will refine our sizing also in the further steps.

We have a development team - people who will do the job, and an agile team - product owner and scrum master (agile coach, team lead). Teams are self-empowered and determined for their own. The development team decides about the sizing. No one can tell them that the sizes are wrong. 

First, development team selects the most familiar one from the ABCDEF features. Similar feature that they have developed in the past. And they decide that one of the features, let say payment option - C, historically they estimated that as Medium size. As they have evaluated one of the features then they are going to compare others with the C feature - comparative view. Lets imagine that they decided that feature A is twice larger than C, so should be XL-size.

Option B is going to take half of the C, then it will be S-size. D is similar to C so will be M-size, E is twice smaller will be XS-size, and F feature twice larger and will be XL-size. 

So, size will help us to determine which features will take less effort, which one will be more effort.

After estimating the size we will estimate duration. Historically Medium size takes them 2 weeks to accomplish. C - is 2 weeks. B will be 1 week, A will be 4 weeks, D - 2 weeks, E - 1 week (we cannot make a half of week), F - 4 weeks.

So at the high level at this point we can say to the customer that we will release an MVP after 7 weeks. And for the second release we need 7 weeks. For the overall project we need 14 weeks. This is not approved schedule - this is high-level. 

The team remains stable in agile from the beginning till the end of the project. Let's calculate the budget. 5-12 people of ideal size (3-8).Lets say we will start with 5 people. Lets say for the 5 people I pay a salary of $1000. First release will be $7000. Second release also $7000. Overall $14000. More detailed planning is the second planning. Second planning called release planning.

At the beginning of each release we will have a meeting called release planning meeting. Development team, scrum master (agile coach, team lead) and PO (customer) will be attending to this meeting. Scrum master will facilitate this meeting and making sure that everyone attending the meeting. We will collect requirements that the stakeholders want to see in this release. 

In traditional we had WBS, here we divide features to requirements or in the term of Agile we call them user stories. Will be collected at the user story workshop. PO will select the best requirements among all.

Who I am as a stakeholder, what requirements I want to see and what value and benefit I think it will get. User stories will be changed then, but MVP’s user stories will be adding more requirements and more details. 

All the user stories are collected in the backlog. Which requirements will get more value to the software will be at the top of the backlog. I see all the requirements in the backlog. This backlog will give you the entire description of the scope.

PO is in the charge of prioritizing the user stories in the backlog. At the bottom of the backlog will be less valuable features. This is not the final scope, backlog will be changed. 

Backlog refinement, or backlog grooming (not using any more). Will continuously refine. It will grow the numbers of user stories in the backlog and I will think that I never will finish a job. Thats why cost and schedule are fixed.

It means that the low level user stories will never be done. But that is fine. 

We will give story points to the each user story in the backlog. What is the size in terms of user stories for each user story. Sizing of one team will be different to sizing of second team. Never compare them.

Planning pocker is the event where team members are giving the size for each user strory. They have to come to the consensus about user story size. Lets say we have collected all the story points and it made 300 story points. So the all projects story points are 300. So we have to done lets say 30 requirements, user stories with the overall size of 300. 

This is my second level of the scope - more detailed one. 

Now we have to determine our velocity. We have to decide our sprint duration. It is 1-4 weeks. We have to decide one of the durations and it will be same during all the project. Sprint is the time-box.

Velocity is the capacity of the team for doing within each sprint. Velocity is selects only team. Noone can select the velocity except team. You cannot compare velocity with other team’s velocity. 

First sprint we will select based on the historical information. Let say team selects 30 story points for each sprint. 300 divide to 30 and we will need 10 sprints. And each sprint is 2 weeks then it is 20 weeks. 

Now we can go back and change the duration in the roadmap. Because it has become more refined.

Sprint goal or iteration goal is the number of user stories we are going to deliver each sprint. Size-estimate-plan.

Now we have a sizing, we know the estimation and we can say in the high level our plan. Most of the time first and second and maybe third sprint will not be changed it is MVP. 

Velocity is the capacity of work, so our goal is to improve the capacity. We cannot add more sprints if our velocity increasing. If we do less job sprint size will stay the same. 

If team complete the job with 20 velocity, not 30. For the second release I will take 20. After first sprint the velocity will be planned as a passed velocity. After 3-4 sprint should be , must be stabilized. We have to stabilize with highest velocity. 

Stabilizing with less velocity is bad. We have to stabilize with the highest velocity at that means that I will accomplish the jobs in the backlog and plus extra work.

We are moving to the third planning - more detailed , more accurate planning called Sprint or Iteration planning meeting. At this stage user stories will be more accurate and more refined.

Sprint planning will be at the beginning of each sprint. All the team members will be attending to the meeting. Sprint goal will be selected for each sprint. 

We will create sprint backlog.

We will decide what is Definition of Done. What is the acceptable degree for each user story. Against to what they will measure the user story. And they have to be agreed with all the stakeholders.