Saturday, December 31, 2016

PMI-ACP Prep: 5 Metrics for Agile Development

This article was first published by MPUG on 12th September, 2016


Let's say you were to meet gold medal winning sprinter Usain Bolt and say to him, "Here's a great track in front of you. You run. We'll monitor your running and declare you the fastest!" Would he run? His response would probably be, "Run against what?" If you said, "Just run, man! Don't worry about the distance!" would he listen to you?

Measurement, it seems, is inevitable and will be expected in many facets of life. In competitive sports or activities, measurement is used to gauge performance and prove who's the fastest or strongest. Judges measure against a baseline, such as 100 meters of distance, which is fixed and sacrosanct -- inviolable so that earlier World records or Olympic records will not be questioned.

But measurement in software development is different. Measurement isn't one developer against others. It's not about declaring someone as the fastest or cleanest coder or quickest bug fixer compared to others. Nor is anybody vying to break an existing organizational record. And baseline, while it should be respected, need not be sacrosanct. The idea of measurement in an unpredictable and complex environment such as software development tends to examine answers to these kinds of questions:
  • What have we done so far?
  • How far away are we from our current iteration goal and overall project goal?
  • What are the areas of trouble in the development team's work? How the team can be helped to do better?
  • Are we improving or what should we focus on for the team's improvement?
  • Are we producing better products with fewer defects?
When it comes to agile development, specifically, those questions apply as well as one of the principles, as outlined in the "Manifesto for Agile Software Development": "Working software is the primary measure of progress."

But how do you measure that kind of progress? In this article I'll share five metrics and their requisite charts, which are important in agile development:

  • Iteration burndown chart;
  • Release burndown chart;
  • Release velocity histogram;
  • Cumulative flow diagram; and
  • Iteration burnup chart.

To understand iteration, velocity and story points, I suggest you read my earlier post on the subject, "Understanding Project Estimation in Agile Development."

Iteration Burndown Chart

A burndown chart such as the one below shows the progress of the team in the iteration. (For Scrum, an iteration is called a "sprint.") Simply put, it's chart that shows the remaining cumulative work for an iteration.

The horizontal or X axis shows the number of days in the iteration; and the vertical or Y axis shows the number of remaining cumulative hours. To plot, start with the number of hours left in the day -- in other words, the total remaining hours. As your team progresses, at the end of every day, plot the remaining hours. Now draw a line connecting the two. Note that many times burndown charts tend to go up in the initial few days as the team may have underestimated or certain earlier unplanned tasks are added, but that need not be the case always. 

A variant of this chart adds baseline information, as shown with the dotted red line in the figure below. You may choose to include it if everyone is familiar with it. But if that isn't the case, adding the baseline may communicate misinformation that your team is doing less work than planned.

You might ask, "Should the non-working days in the iteration be shown?" If you do show it, you are likely to get a reverse S curve. 

Release Burndown Chart

The burndown chart can also be plotted for the release. The horizontal axis shows the number of iterations and the vertical axis displays the number of story points.

In this case we started with 300 story points – the total number of story points for the release. At the end of iteration one we have 270 remaining cumulative story points. If story points are added, then the curve will go up as it has happened for iteration four. 

Release Velocity Histogram

Velocity, as noted in my earlier post, is the sum of story points completed in an iteration. The histogram used to display this metric represents the velocity for each iteration in a vertical bar chart -- planned and actual.

Velocity may not remain uniform throughout the iterations in releases; hence, it's a good idea to show the stakeholders the trend for the last few iterations to give them an idea about what to expect in the future. You can communicate this by drawing over a mean line.

Here I show two types of velocity data: planned or committed velocity by the team and actual velocity. The dotted lines show the averages of the last 10 iterations.

Cumulative Flow Diagram

This flow diagram is cumulatively represented to provide insight into how many items are completed and where the bottlenecks are in the process flow.

In my example I've taken the cumulative diagram for the number of issues coming to the development team on a weekly basis. There are three workflow states: TODO, DOING and DONE.

Obviously, the TODO items are getting added up at a faster rate and becoming fattened, whereas the DOING items aren't able to catch up and flow through a narrower patch, indicating the presence of a bottleneck. Also the team can't seem to move the DONE items well either. From a technical standpoint, this suggests that either the items taken may be very big in size and hence needed to be broken up or that the team is unable to deliver on the issues taken up.

You need to be judicious while using cumulative diagram. It doesn't inform how big or small the tasks are. I've also seen people use a number of workflow states and have lower timescale on the X axis when a high number of issues are being worked upon on a daily basis. There it won’t add much value.

Iteration Burnup Chart

This chart is different from the burndown chart. Here, it's not about remaining cumulative work, rather cumulative work – planned and actual. In this chart, the X axis shows number of days and the Y axis shows number of hours. At the end of every day you plot the number of hours you've worked and connect those points.

Compared to a burndown chart, in this chart the scope changes are visible. If the project has big scope changes (also called "scope creep"), a burndown chart won't help. However, the burnup chart shows both the actual cumulative work done and the planned cumulative work, which, if there's scope creep, will show change.

As shown above, the planned hours started with 600 hours of work. That changed on day 4, where around 50 more hours of work (due to scope change) was added. Then on day 7 there was a scope reduction.

This chart communicates either internally or externally that scope creep is happening. By adding trend lines to it, you can show that if the creep it continues, the items taken for the current iteration won't be fully complete and will require some more time. Otherwise, you can request that the customer stop adding work if they want the features initially requested within the current iteration. Some practitioners don't advise change in scope within the iteration; the scope remains fixed, once the iteration has started. However, scope changes is a reality in many projects.

Final Notes on Metrics

Just as with iterations, you can have both a release burndown chart and a release burnup chart. Other charts I've seen in use are:

• Release burndown bar chart;
• Bug counts;
• Impediment counts;
• Impediments created vs. resolved;
• Bugs created vs. resolved;
• Predicting the end date with trend lines; and
• Combinations of these, such as release velocity burndown with bug and feature count.

Your goal as the project manager is to choose and use the metrics that primarily help your team identify problems and improve productivity.

To return to the running analogy, by using metrics, you're not asking your team members to run like Bolt. Rather, Bolt inspires us to try new things and to continue trying to get better every time we do it -- that is the idea of measurement and metrics.

The Agile Manifesto references this value: "Individual and interactions over Process and Tools."

While there's value in the item on the right (the italicized font), we value the item on the left more (in the bold font).

Metrics aren't there as a substitute for interactions with or among the team members. They're not there to identify which developer is good or bad. Metrics should move your team's path forward, make the development work better and help build valuable software.

Wish all my readers a Very Happy New Year, 2017. 

You may also like:

Thursday, December 22, 2016

PMP Success Story: Mock Exams Give You Confidence And Make The Actual Exam Easier

By Sathish Babu G, PMP

I am passionate about Project Management and want to be a successful Project Manager. I have been hearing PMP® for last 3 years from my colleagues and friends. This motivated and inspired me to be a certified PMP. 

I strongly believed that choosing the best institute and inspiring mentor would be very important to fulfil my PMP journey. So, I have spent some time in the internet and was reviewing the best institutes available in Bangalore. 

PMP Coaching Experience
I was part of Dec 2015 batch. I was very comfortable with the environment, training room, staff, food and facilities provided by this institute.  

Mr. Satya Narayan Dash was our coach. From the very first moment, I was listening his introduction to PMP, his language, the clarity of the presentation and the way in which he presented them. I knew right then and there that this amazing person would be my mentor on my PMP journey.

He is very knowledgeable and very kind. His way of explaining chapters, giving a lot of real-world examples and understand everyone’s concerns are all beyond my expectations. He turned me to be an active listener throughout the training session. At the end of last day of training session, I was able to remember all 47 processes fit into which knowledge areas and progress groups without memorizing them.

Own Study for PMP Exam
Due to new job, new company, new methodology, new roles and responsibilities, I was not able to 100% focused on PMP exam preparation till Aug 2016. But my mind was always thinking and dreaming about PMP. Whenever I see this blog for PMP success story at ManagementYogi, I wanted to be the next. Finally, I have STARTED my sincere preparation from September and mentioned below my study plan.

Books I Referred

Mock Exams

PMP Exam Experience
I have scheduled for the exam on Monday morning, 12th Dec at 8:30 AM. Because morning time works for me and I had weekend before exam to study well and take good rest. I have visited the exam centre a week before to estimate distance, traffic condition, location, parking facilitate, environment and what ID proofs are acceptable.

On my exam day, I have reach to the exam centre at 7:30 AM and they allowed me to take the exam earlier by 8 AM. As instructed by the staff, brain dump is no longer ALLOWED and I was not planned to do either. Surprisingly, I felt that exam is easier and 85% questions were known to me. Because I have spent most of my time to answering mock exams. I have taken more than 5000+ questions.

I have answered all questions in 3 hours and took an hour to review marked questions. I was very sure that I am going to clear this exam and was waiting for 4 hours to complete. I hit the submit button 3 minutes before exam ends and finally CONGRATULATIONS flashed on my screen. I thought of shout loudly, jump and dance. 

Areas from where I faced Questions
Every PMP exam is unique and your experience will be different than mine. However, I am noting down the areas (as I remember) where I faced questions in the exam.

Finally, thanks to:
  • Satya, for your training and most valuable book. You are always inspiring me.
  • My wife, who encouraged me and kept me focused to my preparation.
  • The provider, for the facilities.

Suggestions for PMP Aspirants:
- Dos
  • Understand the definition and key benefit for each process.
  • Understand the following for each process:
    • What you need (INPUT)?
    • What you get (OUTPUT)?
    • How you get (TOOLS & TECHNIQUES)?
  • Where this process’s output feed into & why (DATAFLOW)?
  • Take as many mock exams as possible and review wrong answers and right answers as well.
  • Read questions twice and understand that the question talks about which process and which process group.
- Don’ts
  • Don’t refer too many materials and all available mock exams in the internet.
  • Don’t take mock exams sequentially if you are scoring less than 70% instead do one round of revision and the continue.
  • Don’t memorize 47 processes and ITTOs.

I want to pursue my career into the next level, in the role of a program manager for a high-end project.

Brief Profile
Sathish Babu G working for Kodiak Networks as a Project Manager and having 10+ years of experience in Product, Project Management and Service Delivery in Telecom domain.

Monday, December 19, 2016

PMP Success Story: Learn with Data Flow Diagrams, Must Read the PMBOK Guide and Have Fun While Learning

By Uday Satapathy, PMP

I had a thing in my mind that the syllabus for PMP® is too dreary and the only way to clear this exam was by mugging up stuff, with loads of coffee in between.

Fortunately, as soon as I began my training with Satya, I realized that studying for PMP can be fun as well.

PMP Coaching Experience
I decided to opt for PMP training in October 2016. Satya was our coach. I knew scarcely about him and expected the classes to be grim and serious. On the contrary, the classes were fun and enjoyable – they had to be – else the going would have been tough for us to listen to only the theories.

In the first few hours itself, Satya ran us through all the Process Groups, Knowledge Areas and Processes in a unique and interesting way. A way I believe, which makes the concepts difficult to forget. He promised that by the time the training ends, each one of us will be able to sequentially write down all the processes on the whiteboard. It was hard to believe initially, but eventually it turned out to be true. Suddenly, with Satya's help, the PMP monster appeared less daunting.

Own Study
In the last hour of the training, Satya asked the class to take a test which had predicted how much preparation we would need before we take the PMP exam. I didn’t score that well. Satya suggested that I should prepare at least for 3-4 months before I write the big exam.

I got a bit scared, because I’d aimed to crack the exam with a month’s preparation. That was almost laughably aggressive a deadline, but I’d other constraints in my life and hence I'd no other option. I decided to add 15 more days to my schedule and gave myself 45 days to crack the exam.

I took up Head First PMP book initially, but somehow it didn’t suit me, because I wanted to try out more difficult and thorough books. Rita Mulcahy's PMP Prep worked best for me. I devoured it completely. Every time I completed a chapter from Rita, I would complete the corresponding chapter in PMBOK® as well and take a test. My scores were OKayish.

I finished both Rita’s book and the PMBOK guide finished by November-end. I did a quick revision of PMBOK in 2-3 days and decided to start a marathon of tests, targeting the 3rd week of December for the exam.

I completed all the questions and chapter-end quizzes from the following books:
  • PMP Exam Prep Questions, Answers & Explanations by Christopher Scordo: Lot of questions, most of them easy. But, important for building concepts. Should target 80-85%.
  • PMP Project Management Professional Exam Study Guide, Kim Heldman: Good questions, but a few of the answers are debatable. Target: 75-80%
  • The PMP Exam How to Pass on Your First Try, Andy Crowe: Generally easy ones. Target: 80-85%
  • Oliver Lehmann online questions: Tough and a lot of questions are out of syllabus. I barely managed to scrape through. I guess just passing is enough.
PMP Exam Experience
After the first week of December, while I was randomly checking on the Prometric website for available exam slots, I found to my shock that other than the 14th of December, all other slots were full till the second week of January. I had no option but to book that slot, even though it was only 5 days away, a week earlier than my target date.
I quickly revised both PMBOK and Rita Mulcahy once more, and prayed to God that there be no bouncers in the big test.

Exam Day
I don’t know how it works for others, but surprisingly, in spite of solving so many questions, I found the main exam a bit tough. I took a break after the first 100 questions and noticed that 2 hours had already passed. None of the full length mock tests I took lasted for more than 2.5 hours. However, here I was, sitting in the PMP exam with still 40 questions to revise after 3.5 hours.
I changed my answers for 5-6 questions during the final revision and then submitted it. Soon, the words ‘Congratulations’ flashed on my screen. I was ecstatic, yet completely exhausted. It was time for a celebration :)

Suggestions for PMP Aspirants
  1. The main exam should quickly follow the training – within 3-4 months at the maximum. Else there are high chances that one may lose momentum or forget the concepts.
  2. Learning the data flow diagrams is the best way to understand the inputs and outputs.
  3. PMBOK Guide (difficult one) is a must read.
  4. There are just too many Tool and Techniques to remember. The better way is to understand the logic behind why they are used. There a lot of similarities between them.
  5. Studying a chapter from Rita’s book and then immediately the corresponding chapter from the PMBOK guide worked best for me. That way, I did not have to read the full PMBOK guide in one go.

Brief Profile
Uday Satapathy, Program Manager, HCL Technologies. MBA from Xavier Institute of Management, Bhubaneswar. Certified Scrum Master.

Book Available for PMP Exam:
You may also like:

Sunday, December 04, 2016

Book for PMP Exam Prep: "I Want To Be A PMP"

It gives me a lot of pleasure in announcing the availability of the book for Project Management Professional (PMP®) exam preparation: 

'I WANT TO BE A PMP - The Plain and Simple Way to be A PMP'.

This book is an amalgamation of years of learning during my coaching of PMP aspirants around the globe. Many PMP professionals have referred the contents of this book and have successfully cracked the PMP exam. My students, colleagues, friends, and fellow professionals who are PMP aspirants (many of whom today are successful PMPs) have taught me their needs, expectations from a PMP exam prep book, have motivated me to write this book and also have provided inputs while writing this book. 

Thank You - to all of you for making this book happen. 

This book has been internally published, within inner circles, since September this year. Many successful PMPs have used the this book to clear the exam and many PMP aspirants are currently using this book to prepare for the exam. This blogpost is a formal declaration of the book going fully public. 

Key Features of This Book - "I Want To Be A PMP"

  • Inline with PMBOK 5th Edition with PMP Exam 2016 changes.
  • 100s of tips to crack the PMP exam. This includes inputs from the many successful PMP, who have shared their PMP Success Stories. 
  • Overall 750+ practice questions, including 3 full length questions and question on new PMP exam areas.
  • Numerous diagrams and flow-diagrams to clearly understand the PMP concepts.
  • High simplified content and language. The book focuses on what you need to know for the PMP exam and written in easily understandable content.
  • Many practical examples with usage in real world project management. 

Overall Content of the Book
  • Number of Chapters: 15
  • Number of Pages: 700+
  • Number of Questions: 750+
  • Number of Full Length Question Sets: 3 (+1)
  • Three full length question sets, each with 200 questions and detailed answers (total 600)
  • One additional question set, 4th one with 75 questions and answers, on PMP Exam 2016 Updates

Index of the Book

The index of the book is shown below (Embedded PDF) You can scroll or open in larger screen by clicking the arrow on right in the embedded frame, to see the content. 

If you are want to buy or have any queries on  this book, please drop a mail at

You May Also Like: