Thursday, March 19, 2020

Agile Asanas: Key Guidelines to Follow for “Velocity” (2)



In the earlier part of this article, we saw two key guidelines regarding usage of Velocity in Agile development. In this part, we will see a few more with detailed analysis.

To understand the fundamentals of velocity in Agile approaches, with a hands-on tool of MS Project, you can refer: Understanding Velocity in Agile Approaches with MS Project


*********

Guideline – 3: Always prefer real data for velocity calculation
This guideline is about the usage of real data for velocity calculation. But why is this guideline needed? 


Because many teams start off with Agile for the first time and they don’t have any historical information/data available to show the team’s velocity. You can ask the management to wait for some time before you can give an estimate. But it’s highly likely (and I’ve seen so), management will ask for velocity measure and associated release dates. 

What would you do? 

First, calculate the team capacity, which can be in hours for the duration of the Sprint/iteration. Next, find out the work to be done in the iteration, which can be found from the data of the planning meeting. Finally, use these two – capacity and total work – to arrive at an estimate. 

For example, let’s say: 
  • The team’s capacity is around 100 hours for the week.
    You can ask your team member’s available hours in a week and sum it up. 
  • The iteration’s duration is 2 weeks. 
  • Hence, the team can complete 200 hours’ worth of work in the iteration. 

Next, how do you map these 200 hours’ worth of work with the features that have been committed for the iteration?

For that you have to take Story Points and break it down to hours, i.e., a correlation of story points to number of hours. 

How to do so?

For the sake of our example, let’s say: 
  • The team took a feature estimated at 2 story points (SP). 
  • Next, the team broke down this feature into tasks, and the total estimation comes to be 20 hours. 
  • This makes 1 SP to be worth 10 hours of work.
    (2 SPs = 20 hours; 1 SP = 10 hours)
  • The team can complete 20SPs worth of work in an iteration.
    (200 hours = total team capacity for the iteration; 200/10 = 20 SPs in an iteration)

This becomes the estimated velocity for the iteration, i.e., the estimated velocity for the iteration is 20 SPs. 

But then, the team just followed a big NO in Agile, i.e., correlating story points to hours. This is not advisable. 

Hence, you should preferably use historical information. If your team is pressured to give an estimation, use the way that I just mentioned and clearly inform the estimation approach.

And, most important – discard this data (Estimated velocity of 20) immediately as soon as you get the real data. 


Guideline – 4: Velocity is not a reliable indicator for your project's completion!
Velocity will be used to determine when the project is expected to complete. But use this metric with caution. It’s not a reliable indicator for the project’s end date.

How so?

In guideline – 2, we understood that velocity should be communicated in ranges. This way you don’t fall into the trap of “estimates being commitments”.

When estimates are not commitment, then with an uncertain estimate, you can never say with 100% confidence about the project’s completion. Can you?

Let’s reuse our example – you have a velocity of 12 to 18, i.e., you communicated in ranges. And you have a product backlog of 180 story points. 

Hence the product backlog can be completed in two timelines. The iteration length for the team stays as two-weeks.

With Velocity 12:
  • Number of iterations needed = 180/12
  • Number of iterations needed = 15
  • Project duration = 15 * 2 = 30 weeks 
  • Project duration = 7.5 months

With Velocity 18:
  • Number of iterations needed = 200/18
  • Number of iterations needed = 10
  • Project duration = 10 * 2 = 20 weeks 
  • Project duration = 5 months

Hence, the project can be pessimistically completed in 7.5 months and optimistically completed in 5 months.

This is depicted in the below figure.





Guideline – 5: Velocity is not a measure of productivity

This guideline is derived from the first guideline. We understood that velocity can’t be compared among teams. It’s not an objective estimate and it’s subjective to the team. 

In the linked article for fundamentals of velocity with MS Project, I’ve defined velocity as:

“Velocity is the measure of product backlog items (PBI) delivered in an iteration. It’s the rate at which the PBIs are delivered, validated, and accepted according to the definition of “done,” per iteration. In other words, you can say that velocity is a measure of a team’s rate of progress.”

In addition, I’ve also noted: 
"Velocity is a measure of output (the size of what delivered, such as a 20 story points delivered). It’s not a measure of outcome (translating to value)."

Productivity is quite difficult to measure in any software team. Ideally, when productivity is brought in, it should translate to how much value has been delivered to the customer. Velocity is not clearly meant for this.

More importantly, when you track velocity as a measure of productivity, it again becomes a commitment metric to follow. Also, velocity as we saw depends on how the team is estimating the story points, the capacity available for the team during an iteration, the understanding of the team about the domain involved etc. – all of these are variable items.


To read part – 1 of this article, refer this link.




Agile Asanas Series:



Monday, March 16, 2020

Agile Asanas: Key Guidelines to Follow for Velocity (1)



Recently, I wrote an article Understanding Velocity in Agile Approaches with MS Project, where the foundational concepts of velocity have been explained first followed with a bit deeper dive into this concept. I’ve also explained a practical hands-on approach to determine velocity with a software tool.  

In this Agile Asanas series, we will check-upon a few key guidelines while using velocity in Agile approaches. This is in continuation of Agile Asanas series. In the earlier part, we saw a completely new concept of Naikan and its applicability.

You can read it here: Agile Asanas: Using Naikan as an Agile Practice


*********

Velocity is a useful metric followed in many Agile teams and the calculation for it is quite plain and simple.


Velocity is the total story points (SPs) delivered by a team in an iteration or Sprint. For example, if a team completes 20 SP worth of features in an iteration, the velocity of the team for that iteration is 20. 

However, many teams use velocity wrongly in a number of areas. In this post, I’ll outline a few which I see frequently, e.g., comparing velocity of one team with another, which is a big NO in Agile. So, let’s see the guidelines for Agile teams, if you are using velocity as a metric. 


Guideline – 1: Don’t compare velocity of one team with another

You compare things which are comparable, e.g., you can say one runner is faster than the other runner, one is a better speaker than another, one vehicle is producing better fuel efficiency than another or equipment is producing more outputs than another. You can’t just compare things which are no way comparable, e.g., velocity of the teams. 

How?

Let’s say a team (Team 1) completed 3 features estimated at 5SPs, 8SPs and 3SPs in an iteration. Hence:

Velocity for Team 1 = 5 + 8 + 3 = 16 

Now, let’s say another team (Team 2) completed 4 features estimated at 3SPs, 2SPs, 5SPs, 8SPs, respectively. Hence:

Velocity for Team 2 = 3 + 2 + 5 + 8 = 18

Next, the question which is usually asked is this:

Is Team 2 doing better than Team 1?

No. Because story point – the unitless measure used for the features – is a form of relative estimation. And it’s subjective to the team. 

To know more about story points, refer:
Project Estimation with Story Points in Agile Development

A team which has been working for a long time on a project may estimate a feature at 3 story points (SPs), because they are quite familiar with the project. However, the similar feature by another team can be estimated at 5 story points or 8 SPs or even 13 story points. Because they are learning on a new project. 

It is also possible there can be dependencies, compliance related work or external risks which may increase the estimate to 8 or 13 story points, for another team. Hence the team estimating a feature 8 SPs is no way comparable with a team estimating at 3 SPs. 

Guideline – 2: Give ranges of velocity in your estimation, in place of absolute numbers

The first and foremost problem when you give an estimation in absolute numbers is this: estimates usually becomes commitments. Because it becomes a commitment, you will be required or at least expected to meet that commitment. 

Another problem with absolute estimation is this: it becomes a benchmark to meet, if you meet it once! This will be shown to you, because you have earlier done so. 

A team goes with Agile approaches, when there are uncertainties in technology, requirements or platforms. As there are many uncertain things, agile is both iterative and incremental in nature. 

To know more about iterative and incremental developments, refer:
Why and When To Go For Agile Life Cycle

Hence, in an uncertain environment, it’s futile to give an absolute number. For example, let’s say a team has these velocity measures:
  • Iteration 1: Velocity = 12
  • Iteration 2: Velocity = 16
  • Iteration 3: Velocity = 17

A histogram representation is shown below.



Next, many times, I’ve seen teams are enticed to give an average velocity, i.e., (12 + 16 + 17)/ 3 = 15. But what happens if the team has less velocity in the next iteration? 

Let’s say for the next iteration the velocity comes as:
  • Iteration – 4: Velocity = 13
This is shown in the below figure. 



You had earlier communicated the velocity (average one) to be 15. Now the velocity has come down to 13. It’s likely that your management will ask questions. And of course, it also looks bad. 

What should you do?

You should communicate the velocity in range, i.e., 12 to 18: 
  • 12 as the worst-case scenario.
  • 18 as the best-case scenario. 

With this approach, other stakeholders realize that velocity measure given is not a commitment, but a range. And if you don’t meet the earlier one given, nobody will complain or ask questions, because they know it’s in ranges, not absolute numbers. 

To read part – 2 of this article, refer this link.



Agile Asanas Series:


Saturday, March 07, 2020

Why and When To Go For Agile Life Cycle



Projects, like human beings, are living entities. Just as every human being goes through a life cycle, so does a project. To understand life cycles, let’s break down a real-life example. Every day, you wake up from your bed, do your morning chores, have your breakfast, do your work, come back home in the evening, give some time to yourself, and then retire again to bed. Would you say these activities constitute a life cycle?

Think about it for a moment.

Did you think that your daily activities formed a life cycle? I guess not. It is not a life cycle because you are waking up the next day to do those same activities again, aren’t you? I hope so. I don’t expect to leave the world tomorrow, and I don’t think you do that either, so, our daily activities, in fact, constitute our daily routines rather than a life cycle.

What is a life cycle then?

Your human life cycle began when you were born into the world. You’ve passed through or will pass through many phases—infancy, adolescence, young adulthood, old age, retirement. Every one of us will have to leave the world one day, too. Your life cycle spans a timeline from you being born into the world and finally leaving the world. Similarly, the life cycle of a project spans from the time it is born into an organization and created until it is finally been finished or closed.

Why are life cycles so important? I’d like to suggest the importance is because a life cycle determines what things you do in your life and how you do them. Let’s say you had a good childhood, you received care in your upbringing, and hence, you grew well in later stages. With a good beginning, as you aged, you were able to contribute back to society in a positive way. Similarly, a project’s life cycle selection and correspondingly the development approach impacts how the project is going to be executed, led, managed, and finished. Life cycle dictates how a schedule will be managed, how cost will be estimated, how budget will be determined, how requirement changes will be addressed, and how various stakeholders will be engaged, etc. If all of this is determined and executed correctly, then the output of the project—product, service, or result—is expected to be a good one.

Various Life Cycles
PMI’s PMBOK® guide 6th edition documents that a project life cycle is a series of phases from its start to completion. The project life cycles can be predictive or adaptive. However, within a project, there can be one or many phases of development. These constitute the project’s life cycle, as depicted in the figure below.




Development life cycles can be of many types:
  • Predictive Life Cycle
  • Iterative Life Cycle
  • Incremental Life Cycle
  • Adaptive Life Cycle
  • Hybrid Life Cycle

Understanding life cycles and selection of life cycle are important concepts while preparing for the Project Management Institute® Project Management Professional (PMP)® or Agile Certified Practitioner (PMI-ACP)® examinations. If you are a project manager, you also know that every project is unique, and you want to implement a good understanding of the various types of life cycles when tailoring a project’s development according to your need. This is where life cycle selection plays a crucial role.

Predictive Life Cycle
This life cycle is also known as “Plan Driven,” “Fully Plan Driven,” or as the “Waterfall Model.” The later term has been used in the last century mostly to refer to software development. The scope is known early in the life cycle, and you know exactly what the time needed and cost requirements are to deliver. In summary, this life cycle is used when the product to be delivered is well understood.

In many projects; however, requirements and scope are rarely known in detail before the project begins. As details and finalized scope is not known in advance, you can’t have the time and cost known in detail either. And so, this leads to another life cycle—the iterative life cycle.

Iterative Life Cycle
Here, you deliver in iterations by progressively refining the product every step of the way. The concept of progressive elaboration fits in here. Progressive elaboration is basically an iterative process of increasing the level of detail as greater amounts of information becomes available.

Both the product containing unclear requirements and the plan having unclear estimates are progressively elaborated. The product is developed over a series of iterations. The detailed scope for the current iteration is only known at the beginning of the iteration. You incorporate the feedback from previous iterations into the subsequent iterations.

Incremental Life Cycle
In some projects, there can be complexities with respect to technology or the platform being used. Now, this is different from low agreement or lack of clarity on requirements. This is the case where the customer is wanting the deliverables quickly.

Also, many times, it’s not important how well-refined your product is or how beautifully it’s done. Rather, the focus is on speed of delivery. In such cases, you can use the incremental life cycle.  Here, the delivery that you give to the customer can be immediately used and/or the product increment is potentially shippable.

Adaptive Life Cycle
Our next cycle to explore is the adaptive life cycle. It is also known as the Agile life cycle. Agile development is both iterative and incremental (or I&I).

Many confuse iterative development with incremental development. They are not same.



Incremental development and delivery means that a product is developed in small chunks—not all at once. This is shown on the left side of the above diagram. Here, we take the highest priority features, as prioritized by the customer, first and foremost. When the highest priority features are delivered, the customer get the highest value features first. In incremental development, all features that you develop, should be fully complete or done.

Iterative development, on the other hand, means we deliver in iterations. We deliver a skeleton product or a prototype first. The next delivery is based on the feedback from the previous iteration(s). Then, with successive releases of the product (a release being a set of iterations), the product is refined further.

Remember, an Agile life cycle is both iterative and incremental?

In Agile life cycles, products are developed in iterations, a series of them. Each iteration also incrementally builds the product, and at the end of iteration, a deliverable or a set of deliverables is completed, as shown below.




To understand these life cycles, we will take a look at a popular diagram used by Agile practitioners, Stacey’s Diagram.

Stacey’s Diagram
On the Y-axis, we have the agreement (typically on requirements) and on X-axis, we have uncertainty (typically on technology or platform). You can also say the Y-axis is about “what to do,” whereas the X-axis is about is “how to do it.”


For simple projects, shown on the lower left side of the above figure, you know exactly what to do and how to do the work. Those simple items are rarities in software development and may not show up at all, other than perhaps in maintenance projects. If a disagreement on requirements comes up, you can use the iterative cycle, or if the technology complexity increases, you can use incremental cycle. These are items which are shown as “complicated” above.

At a high level of requirement complexity and a high level of technological complexity, the Agile life cycle is best. In other words, in “complex” projects, as shown in the above diagram, we take an Agile approach. Here, the iterations are very rapid and usually completed in a 2 to 4 week time period. Since it is also incremental, you get successively added functionalities. The adaptive approach is implemented in a rapidly changing environment, when requirements and scope are difficult to define in advance. At the end of each short and time-boxed iteration, there is a retrospective session or feedback meeting. Information collected from this session is incorporated into subsequent iterations.

We can also put it in another way, as shown below:



When you have high agreement on requirements or low churn in requirements and low uncertainties, you go for predictive mode. However, if the requirement churn is high (for example, there is a high degree of change) or the clarity on the requirement is not there, the project will be running in an iterative mode. For finished work that your customer may want to use immediately (such as high frequency deliveries), apply an incremental approach. Finally, go for Agile, when you iterate many times and are creating deliverables at the end of every iteration.

Advantages of Agile
The Agile approach has many advantages over traditional or fully plan driven approaches.
  • Since the iterations are short and time-boxed, the team stays focused on the current iteration and delivery.
  • The highest priority features are taken into consideration. Hence, the customer immediately gets value on them instead waiting for a longer time.
  • High uncertainties mean high risks. The biggest risk a project can have is failure to deliver anything, or delivering something that was not originally intended. You cut down on these risks by delivering, not only early, but frequently.
  • The customer gets an incremental version of the product at the end of every iteration. Hence, value is produced often, not just early.
  • As the delivery happens rapidly, so also is feedback gathered. The issues, problems, new features, and/or emerging features can be incorporated into subsequent iterations.

I hope you’ve enjoyed this in-depth analysis into the various life cycle’s available within project management. As you can see, it is important to choose the correct one or the correct combination as it relates to the needs of your customer. More often than not, for complex projects, a flexible Agile approach, is the best.

References:
[1] I Want To Be An ACP: The Plain and Simple Way To Be A PMI-ACP, by Satya Narayan Dash
[2] Project Management Body of Knowledge (PMBOK) Guide, 6th Edition by Project Management Institute (PMI)
[3] Agile Practice Guide, by Project Management Institute (PMI)
[4] Agile Project Management with Scrum, by Ken Schwaber
[5] I Want To Be A PMP: The Plain and Simple Way To Be A PMP, by Satya Narayan Dash

This article was first published by MPUG on 17th April, 2018.



You May Also Like:

Other Agile Artcicles:


Sunday, February 23, 2020

PMP Success Story: You Don’t Have to See the Whole Staircase, Just Take the First Step

By Tanushree Bhoi, PMP




Introduction
I wanted to advance my skills in project management. Hence, I decided to achieve the Project Management Professional (PMP®) credential offered by Project Management Institute (PMI®). This was my primary motivation.

PMP 35 Contact Hours Experience
After doing some research, I came to know about a provider at Bengaluru which provides good 35 contact hours of project management learning experience. The reputation had been built-up primarily due to the Satya sir. These contact hours are mandatory for PMP exam eligibility. 

For the first time here, I met Satyanarayana Dash Sir, who has a unique style of teaching. Post his sessions, I got motivated to prepare for the exam. I liked the way he had explained the 49 process flows of the PMBOK® Guide, which is very important to clear this tough examination. 

Also, he always added some humour to his teaching, which made it easy for me to remember some difficult aspects of this course. 

Own Study
I’ve had a very good learning experience with Satya Sir in those four days and came to know about his book: I Want To Be A PMP. As I was very happy and comfortable with his teaching and training style, I bought his book. 


However, due to various reasons, I could not prepare much post the sessions. I finally submitted my application which was selected for audit. I was asked to update my project information in PMI’s language and not in general resume style. For Audit, I had to send all hard copies of my certificates and filled audit-forms to PMI. My application was approved on the same day when the documents reached PMI’s headquarters in the US. 

I was reading for the exam, but it was not a full-fledged preparation till the end of 2019. In November, 2019, I realized that my one-year membership subscription with PMI is going end and hence, contacted PMI for an extension. Along with that, I finally decided to go full throttle and sit in the exam. And, I scheduled my exam for 23rd January, 2020. 

I cannot exactly say the duration of my preparation, but I think I really started studying from October 2019. I was used to spend 2 to 3 hours regularly. But the last three weeks before the exam, i.e., 3 weeks before the 23rd January date, I was spending nearly 8 to 10 hours in focused studies. I knew as I have already scheduled the exam, these will be crucial for me. 

First, I studied in the sequence of knowledge areas as outlined in the PMBOK guide, and then, I studied in the sequence of process groups.

Study materials
I referred the below study materials. 
  • Book “I Want To Be A PMP” by Satya Narayan Dash: I read this book three times. This was my primary reference. 
  • Book by Rita Mulcahy and Andy Crowe: I browsed through and did some of the chapter end questions.
  • PMBOK Guide, by Project Management Institute: I only read 3 process groups – Initiating, Closing and Executing. I referred this guide only when needed.
Other than the above books and guide, I referred Prepcast for mock tests. I scored nearly 80% in my first attempt and was reaching 90% in my second. 

I found my speed was good and I was able to solve 200 questions in 3.5 hours. I used to review all failed (and few passed) questions. My weak areas were primarily in these knowledge areas – Procurement Management, Quality Management, Schedule Management and Cost Management. To fill the gaps, I again referred the chapters using the above material. I also used to watch some content from the YouTube to get more clarity on few topics. Many times, I’ve reached out to Satya Sir to clarify and he would always respond with justifications for the answers. 

In addition, I also used Christopher Scordo’s PMP questions, where my score was varying between 70% to 80%. 

Book Review - I Want to Be A PMP
I would say this book is one of the best study materials I had for my PMP exam preparation. The contents of the book are very simple and aligned with PMBOK guide’s process groups and knowledge areas. 


The best part the book: it has a large number of tips in every chapter, which is very useful to connect all the processes. Another area is it sequences and connects the 49 processes across the knowledge areas in a logical way. Complicated, difficult knowledge areas like Integration Management and Procurement Management are written in an easy way to understand, which are crucial for the exam. 

This book has also provided spreadsheet with all Inputs, Tools and Techniques (ITTOs) and it’s a single file where you can apply filters to know the ITTO immediately. It was beneficial for me to refer to this sheet while attempting any mock questions. 

This book helped me to connect all processes in an easier way which I did not find in any other PMP preparatory books. I liked the videos provided in this book on change management (extremely important for the exam), conflict management and interpersonal and team skills. The book has references to few articles written by Satya Sir which is good to understand, e.g., key concepts like resource levelling and resource smoothing.

I highly recommend PMP aspirants to read this book.

PMP Exam Experience
I must say the exam was very difficult for me. May be because I was expecting the kind of questions where I was scoring 90%. 

Hardly 20 or 25 questions were straight/direct and the rest were all situational. I was able to eliminate two answers easily but was confused with the rest two. It was like 2 + 3 = 5, but so also 6 - 1 = 5! 

During mocks I never had issues with my time management. But in the real exam I ended up doing only 30 questions in the first one hour. I was stuck in many questions in the first one hour. Four hours were short for me and I got a message saying I have only five minutes left when I was solving question number 182. 

I was constantly praying and trying to control my anxiety during the exam. Then it automatically got closed when I just completed 185 questions. 

But then, immediately in few seconds I saw congratulation message. Such a great relief!! My final score was Above Target.

I could complete only 185 questions in 4 hours. I could not take any break during the exam. I didn’t get time to review five to six questions, which I had kept for reviewing. 

I received the followings types of questions:
  • Many questions will ask what the project manager will do NEXT. A situation will be given and you will be asked what you would do next. 
  • I received few mathematical questions on Earned Value (EV), Planned Value (PV), Actual Cost (AC), Schedule Performance Index (SPI), and Cost Performance Index (CPI). In total, they will be 4 to 5 and they were simple mathematical calculations. 
  • I received around 20 questions on change requests, change management. 
  • There were many situational questions with respect to these knowledge areas – Risk Management, Resource Management, Procurement Management and Stakeholder Management. 
  • Few questions were touching multiple knowledge areas and it was difficult to identify which process and process group I am in. 
  • Few questions were there on different contract types, stakeholder analysis, project charter (important to know what it includes and what not), business documents, tools on quality management, critical path analysis, and data analysis techniques.
  • I received few questions on agile framework and approaches – around three to four questions.

Suggestions for PMP Aspirants
Dos: 
  • It’s important to decide and schedule your exam at least 45 days before your exam date. 
  • Focus on understanding all 49 processes. You need to understand why these are input or output or why these tools or techniques are used in a process. 
  • Read a good PMP preparatory book and/or PMBOK with which you feel comfortable. You need to read multiple times until you understand the process flow. 
  • Initiating and Closing process groups have in total just 3 process. Hence, you must read to score well. 
  • Executing process group has 10 processes and it’s very important because you will have more than 60 questions in the exam. 
  • Planning process group is vast, but this process group is easier than Monitoring and Controlling process group. 
  • It’s important to go through PMP exam content outline (ECO) as the PMP exam is based on its content outline and not on PMBOK guide. 
  • Work on your time management for real exam. 
  • Remember to visit the exam centre once before you go there for the real exam date. 

Don’ts
  • Don’t memorize anything without understanding.
  • Don’t spend more time on math questions if you are not good at math. If you are good at math, then you must do these because math questions will have only one correct answer. You need to remember a few mathematical formulas for that. 

Conclusion
I’ve learnt a lot during PMP preparation which is beneficial for my personal and professional life. I’ve outlined my experience on what I remembered. I believe it will help you in your journey to be a PMP. And wish you all the very best. 

Brief Profile:
Tanushree Bhoi, PMP
I’ve more than twelve years of experience in information technology (IT) sector with over eleven years of experience in developing and implementing quality assurance (QA) processes and leading software QA teams. 

I had to take a sabbatical for couple of years due to personal commitment in bringing a new life to this world and building, sustaining it. I’m currently looking for new opportunities and looking forward to use my project management skills and get back to project management areas. 





PMP 35 Contact Hours Online Course:
PMP LIVE LESSONS - Guaranteed Pass: