Thursday, December 31, 2015

Year End Post - Practical PMP with MS Project 2016




Good news for professionals who are aspiring to be a PMP in the coming year - 2016. You will learn theory with new changes coming for the PMP exam as well as the practical aspects of project management with new software available from Microsoft - Project 2016.

PMP exam is going through certain changes in 2016 - most important being the emphasis on business strategy, business benefits, benefits realization. Hence, the role of a project manager will also be changing. Microsoft has released its new version of its project-portfolio management software - Project 2016. It includes a host of new features. To know more on these changes on PMI-PMP exam and MS Project 2016:

Based on these new changes to PMP exam and MS Project software, the new course - "Practical PMP with MS Project 2016" - is being released. It will have all the changes mentioned for the new PMP exam. Also, PMP aspirants can use the new MS Project 2016 as a hands-on tool to understand the theory. 

To know how theoretical aspects of PMBOK Guide can be used with a hands-on tool like MS Project 2016, a new whitepaper has been made available to you for free.

Some of the changes for the PMP exam, which are part of the new course:
  • Goals, Strategy and Objective
  • Business Strategy, Business Benefits, Benefits Realization
  • Strategic Alignment of Projects and Role of Project Manager
  • Managing stakeholder engagement and relationship
  • Project charter and role of project manager in charter development
  • And more...
Some of the changes for MS Project 2016, which are also part of the new course:
  • Multiple Timeline View
  • Resource Engagement and Resource Plan View
  • Tell me what you want to do feature 
  • And more...
For more details refer the "Complete Courseware" document - link available at the end of this post.

This is on top of host of new updates that had happened to "Practical PMP with MS Project 2013", in the beginning of this year. It has been outlined in the below link.

The project management profession is evolving with new changes coming for the PMP exam in 2016. Simultaneously, I firmly believe project managers need to be thorough in applying the practical aspects of various theoretical concepts mentioned in the PMBOK Guide. Best part is PMP aspirants find this course very useful in the classes that I conduct on Practical PMP, where the 'Aha!' moment frequently comes up. They use the tool - MS Project and also see various techniques that can be performed with the tool - critical path, resource leveling, resource smoothing, schedule compression, stakeholder register creation and updates, resource management, cost management, earned value management - to name a few. 

Below, the updated content for Practical PMP with MS Project 2016, if you want to know what will be available for you in this course.

Updated Course Content: Practical PMP (includes PMP Exam 2016 Updates) with MS Project 2016:
  • Practical PMP with MSP 2016 - Course Overview (Link)
  • Practical PMP with MSP 2016 - Complete Course Detail (Link)
  • Practical PMP with MSP 2016 - Certification Process for PMP, MS Project (Link)
  • Practical PMP with MSP 2016 - Course Benefits (Link)
  • Practical PMP with MSP 2016 - Frequently Asked Questions(FAQ) (Link)

I am certain this course will provide immense benefits to aspiring PMPs, who want to have proficiency with MS Project 2016 - side by side.

Wednesday, December 16, 2015

PMBOK 5th Edition with MS Project 2016 - A Practical, Hands-On Guide




The whitepaper "PMBOK 5th Edition with MS Project 2013 - A Practical Guide" and its earlier edition since 2009 have been used as a reference in many management articles and periodicals. Shorter versions of it, with certain summary items, have been published by international publications. I have seen many downloads of the paper from the drive it has been shared from. Considering its popularity, I have this new paper "PMBOK 5th Edition with MS Project 2016 - A Practical Guide for Time Management". 


Also as MS Project has up with its new version - MS Project 2016, which has new functionalities such as multiple timeline bars, custom date ranges for a single view, style theme change, 'tell me what you want to do', I believe it is time to update the white paper. 


This paper is an enhanced version of "PMBOK 5th Edition with MS Project 2013". I have added on the other Resource Optimization Technique, i.e., Resource Smoothing. Resource calendars which can come from HR Management and also Procurement Management have been added along with a flow diagram depicting them all.  And of course, complete white paper is tested with the new MS Project 2016. 

Few excerpts from the paper:
During planning, Scope Baseline is created in “Create WBS” process of Scope Management KA. Schedule Management Plan from “Plan Schedule Management” along with the Scope Baseline from “Create WBS” are fed into “Define Activities” of Time Management KA to create activities from the work packages. These activities are then sequenced in “Sequence Activities” process to create a Schedule Network Diagram.  
Simultaneously, Resource Calendars from “Acquire Project Team” process of HR Management KA and “Conduct Procurements” process of Procurement Management KA act as inputs to find out the resource estimates, duration estimates. Schedule network diagram, resource estimates (or requirements), duration estimates and resource calendars finally create the Project Schedule in “Develop Schedule” process. Develop Schedule also creates Schedule Baseline for the project, which is then monitored and controlled in “Control Schedule” process. 
The overall interaction of the processes of Time Management HR Management and Procurement is shown below along with certain inputs and outputs. 

I have made this paper free since PMBOK 4th edition and MS Project 2007. Following the tradition, this paper is also free for my readers. Click on the pop-out icon on far right of the below embedded view to see it directly over the drive or you can scroll to view the content.

The complete paper can be downloaded for free. (PDF Link)

You may also like:


Sunday, December 06, 2015

PMP Prep: Qualitative Risk Analysis vs. Quantitative Risk Analysis



As you're preparing for your PMI® PMP® exam, you'll want to understand the basics of qualitative risk analysis (QLRA) and quantitative risk analysis (QTRA), both processes that are part of the "Project Risk Management" knowledge area. While these two concepts sound similar and both use numbers in risk rating, they're not the same at all. Test-takers often get confused about how they work, how they vary and what unique roles they play. Adding to the confusion, QTRA can be optional! Both QLRA and QTRA are powerful risk analytics, and both have a place in project risk management. In this article, I explain their distinctive roles, show where they differ and illustrate what happens when both are used.

The PM Book of Knowledge risk management knowledge area has six processes that interact with each other:
  

All possible risks are identified in the "identify risks" process and put into a project document called the "risk register." Then qualitative risk analysis is performed. From there, it may lead to quantitative risk analysis or directly to risk response planning. In other words, quantitative risk analysis is optional, as indicated by the dotted line. If both QLRA and QTRA are performed, they'll be in close sequence and the risk register will be updated for both types of processes.

In its simplest form QLRA is the process of evaluating individual risks from the "Identify Risks" stage for their probability or likelihood of occurring (the "P" value), multiplying that with the impact the risk could have on the project objective (the "I" value) and then prioritizing the risks based on their ultimate "risk score."

QTRA is the process of providing numerical estimates of the overall effect of risks on the project objectives when all risks are considered simultaneously. The numerical estimates are usually in terms of schedule and cost. The prioritized list of risks created in the QLRA process is further updated in the QTRA process, based on the numerical estimates.

Why is QTRA optional? As a project manager, you operate in a highly constrained environment. Sometimes, you have to leave something out because you lack time or budget, particularly in smaller projects. So why perform QTRA at all? We'll look at that shortly.

When only qualitative risk analysis is conducted on a project, it's known as "partial risk analysis."

How QLRA and QTRA Differ

The fundamental difference between QLRA and QTRA is that the first addresses individual risks of a project, whereas the second considers the overall project risk. The overall risk to the project is due to the combined effect of all risks and their possible interdependencies and correlations. Overall risk applies to the project as whole, rather than individual activities or cost items in the project.

Note that both QLRA and QTRA use numbers for risk rating and prioritization of risks. But QLRA is a subjective evaluation, whereas QTRA is more objective in terms of value or cost terms. In QLRA, for example, the risk rating could be "5" or "10" after multiplying the P and I values of the individual risks. For QTRA you establish the overall cost or time impact on the project, such as: "$25,000."

Let's look at a sample risk register that has been compiled through the "Identify Risks" process. In this example positive risks are known as opportunities and negative risks are known as threats.


In QLRA, the probability and impact values are assigned and the risk score is set. Probability values may be textual (low, medium, high); graphical (red, orange, green); or numerical (1 for low risks, 5 for high risks or somewhere in between). Each risk is assigned a probability value and an impact value and the risk score is calculated. It's not uncommon to combine the numerical and graphical values to have a color-coded indicator.

The updated risk register in the figure above, which summarizes the output of the QLRA process, is sometimes known as the "qualitative risk register." The register may contain other information, such as identification date, identifying person, cause, effect and risk exposure. Based on the risk scores, you perform the prioritization of risks; if the score crosses risk tolerance limits for your organization, then you know you have to take a risk response.

As I noted earlier, QTRA is performed after QLRA. In the QTRA, you quantify some of the items from the qualitative risk registers and assign a cost value. The updated risk register, as shown below, is sometimes referred to as the "quantitative risk register."


Notice that the register may contain other information such as impacted activities of the project, correlation and probabilistic distribution details, among others. In my example, I've used expected monetary value technique (EMV) for further prioritization and subsequent risk response planning on the quantified risks.

Differences between Qualitative and Quantitative Risk Analysis

In addition to the differences between QLRA and QTRA that I've already mentioned, others also exist, which I've summarized in the table below.



Both qualitative and quantitative risks analysis are important for project risk management. As aspirants for PMP certification, you need to know that both QLRA and QTRA play distinct roles in project risk management. Also, you need to understand the key differences between them to tackle your exam.


This article was first published by MPUG on 25th August, 2015. 

Note: For the Risk Management Professional (RMP®) examination by PMI, this exhaustive list of differences between QLRA and QTRA, will also help you prepare. 



Tuesday, November 24, 2015

Agile at Scale – What to Do When a Sprint is Cancelled?



At one of the lowest levels of Scrum development, you have Sprints. If you are combining Scrum with Kanban or have another iterative and incremental development, then you are likely to have iterations. In either case, with a small team and one Sprint backlog, it is easy to manage the dependencies, have the needed integration and deliver. When you have multiple sprints (iterations) running in multiple teams, the complexity increases in managing dependencies and delivery. 

In such case, synchronization of Sprints is a practice for Agile development at scale.  In place of overlapping Sprints, it is advisable to have synchronized Sprints for good collaboration and dependency management. Now, what happens when one of the Sprints - synchronized with same length or nested with different length – gets cancelled?

Sprint getting cancelled is rare, but it might happen, e.g., when the goal of the Sprint is no longer relevant.

Say there are Sprints of different lengths with a cancelled Sprint for one of the teams. The situation looks like this as shown below (Figure - 1). I have 3 teams – Team 1, Team 2, and Team 3 - running Sprints. The Sprint lengths are different. For Team 2 and Team 3, it is nested inside the Sprint for Team 1. But, Sprint 1 for Team 2 has been cancelled for certain reason.


Figure - 1
So, what can be done in such a case? Will the team immediately start the next Sprint? If not, will the team seat idly? 

Some suggest that add on the days leftover from the current Sprint to the next Sprint and start off, which is like the one shown below (Figure - 2). As shown below, Sprint 2 of Team 2 has been extended to start some days before. Note that I have shown first Sprint getting cancelled. It may be other Sprint in the development cycle.

Figure - 2
In my view, it is not a good idea. There are certain reasons which I will outline.

First, Sprint cancellation is not an easy thing to digest by the team members. Let the team find out what went wrong or if by external reasons, what could have been done better. That takes some time. Starting off immediately, does not help address this case. In fact, I would suggest to have a small retrospective of what went wrong and how it can be avoided. 

Second, the changes that you have made to the codebase while running the Sprints have to be commented out or removed or placed into separate classes or packages, as they may not used now. The branches that been created to have the code checked in and tested have to be tagged as such. If they have merged to the main branch (if there are dependencies with other team), have also to be addressed. These take time. 

Third, though I am saying that Sprints can be of different length in different teams, I am also suggesting for the same team keep the team length same. Going forward, for every Sprint, I would like to see improvement in terms of delivery, e.g., by checking on the velocity. This is not possible if we change the length for the same team. 

Fourth, Sprint length should be kept at same length (at least for 1 or 2 quarters) because it helps in reaching a high productive state. If you keep on changing the lengths, it breaks the rhythm

Fifth, think of distributed environment where Sprints are running. How can the next Sprint immediately start off, if the previous Sprint is cancelled? It is just not practical.

After the cancelled Sprint, start the next Sprint as depicted below (Figure - 3). Have the next Sprint as scheduled earlier, which you would have done in your release planning. 


Figure - 3
So, what the team will do for the time left? There are many things that can be done, e.g., doing a small retrospective, Product Backlog refinement, technical debt payoff, making the changes to the branches etc.

You may also like:



Wednesday, November 11, 2015

PMP Success Story: Remove Your Mental Block, Open Up and Think in Terms of PMBOK’s Best Practices




Aswin Krishnan H is a proud PMP today. His success is not only due to sound preparation, but also handling stress during the exam. He names it as the “smile” factor, as he has told below so uniquely. 


Aswin was part of my class in May, 2015. He is a very lively person and participates fully. In fact, I remember few instances where his enthusiastic participation were bringing surprised looks on some faces. In my view, enthusiasm is a great quality in any team member. But, unfortunately, it is highly underrated. I believe, enthusiasm is contagious and brings many into the fold of discussion. He called me after he was certified and I asked – “How does it feel to be a PMP?” He had a sense of happiness, relief and immense satisfaction. 

Below, he has outlined his experience in preparing for it, going through the PMP program and finally cracking the exam. Go on and read his experience.

*******

Introductory – Why I decided on it and how I started?
I was motivated to do PMP as part of my job and wanted to understand properly the Best Practices and how to use them with confidence in day to day activities as far as possible.

Three of my friends were equally interested in doing Industry standard certification and when we began our search we had PRINCE 2 and PMP in our mind. Finally, we settled down with PMP which has huge demand in any industry. We then started our search for Training provider, found that it’s the Coach and his approach that help a lot in this kind of Certification, though online and word of mouth reviews.

One of my friend had a successful experience in securing his PMP within a month after training with the Coach Mr. Satya Narayan Dash, He was really impressed by his practical approach, knowledge and personal commitment. He has previously attended PMP trainings from various centers but never could understand the concepts clearly, and failed in the exam miserably. He came from Chennai to do the course in Bangalore, just for the Coach.

My PMP Training Experience:
The training was very precise and covered all Knowledge Areas from the 5 Process Groups: Initiating, Planning, Executing, Monitoring and Controlling and Closing. Satya was very kind and use to share his personal experiences with certain problems which helped to see insights of approaches and reason why or what suits best based on the PMBOK Guide. He always helped us think about all the process and why each Input is given and what is the output of each process and why it is important, often in many of the companies we don’t practically use all the process or tools but the Coach’s insight in all tools and approaches was very helpful in understanding the Input, Tools and Techniques and Output (ITTO) for each Processes.

We had classes on Weekends, the coach was very punctual and kept his timelines very strict. He was very happy to help even after the classes and he would stay back for us even if it was raining just to make sure that we get the idea of what is happening or why it is happening, He use to explain ‘Change Request’ or ‘Deliverable’ Flow by drawing pictures as it goes through each processes. These insights really helped in understanding the concept and the interrelationship between each process and ITTO.

In the entire class there was fun, all were active and were participating which the coach always managed to make it interactive. Lot of things we need an actual physical person to explain to us rather than just going through hours and hours of Videos. I understood that having a real person standing in front of us will build that physiological effect, which will help me learn more and get motivated easily.

My Own Study:
I really wanted to complete the exam within 2 months after completing the class, but due to personal commitments it got extended to 4 months. Every-day I use to spend at the least 2-3 hours reading PMBOK 5th Edition, Rita Mulchay. This really solidified my understanding that was gained in the Classroom training. 

In the last one or two months I use to keep on giving Mock Tests in the early mornings (4 -7 am) and then review them after coming back from work (7 - 8 pm), I kept on giving mock test from various places and was not be very subjective in selecting the source for exam. I felt that giving these mock tests really boosted my confidence and triggered to schedule the exam. While doing the mock tests most of the times I was in panic and I didn't read all options and selected the wrong one. Rita Mulcahy's recommendation helped. I read the options from D to A instead of A to D. This really increased my hit percentage.

My PMP Exam Experience:
I became a member, filled in my application, got my references and waited for a week to get it approved; luckily it was not selected for any audit. That was half way done, second challenge was to schedule the exam. I kept on giving mock tests until I had the confidence and was hitting 75-80% in mock tests. This triggered me to schedule an exam, at this time I just wanted it to get over at the earliest; luckily I found a date that was within 10 days and scheduled the exam on that day.

I had formulated this strategy of completing 70 questions in an hour so I will be done within 3 hours at the max (200 questions) this I kept on applying while taking the mock tests and this strategy was quiet successful for me.

On the Test day, I was faced with a flurry of Mathematical questions (20-25) from Question No#1 with all confusing stuffs and very wordy; I was very stressed, then I remember reading somewhere that even if you are stressed and if you manage to keep a smile on your face you can beat the stress. I applied the same and was able to get over the initial surprises in the exam. There were lots of situational questions, I was confused in lots of places; I marked them and kept on moving forward without worrying about the lengthy or wordy questions and kept on answering whichever I could. Finally, by the time I was done with 200 questions, it was like 2:30 hours; so I went back and selected all the unanswered and marked ones and slowly went through each one of them, now ‘smile’ factor worked and was able to easily and clearly read the questions and answer them. I completed all left outs within 45 minutes. Now I started reviewing again from beginning and just kept on speed reading questions and selected answers just to make sure that I did them correctly. The PMP really puts a toll on you with all sorts of Mathematical, Situational, and Tricky Questions, the initial impact of the questions is really intended to create stress, if you overcome that then you would be able to score very easily. During the exam I read the answers from D to A instead of A to D, I found this to be very helpful against panic answering due to stress.

Suggestions for PMP Aspirants:
- Dos
  • Please read PMBOK at the least twice, it is very helpful and answer to PMBOK and not to your personal experiences.
  • Please take any book like Rita or Andy Crowe or Head First and complete them once before kick starting the mock tests.
  • Please keep a smile on your face, even though you are stressed, this will help relieve stress and get back to your senses while taking test, if you are in panic answering mode read the answers from D to A than from A to D this will improve your hit rate, these helped me.
  • Please do take 10-15 mock tests before attempting the exam, this really helped me understand where I stand and what my weakness is and helped to motivate and improve.
  • Real life PM experience helps a lot while answering these questions during the exam.
- Don’ts
  • Don’t waste time prolonging the exam, use your time wisely and complete it at the earliest.
  • Having too many materials won’t help as you will be confused when to complete them, don’t get overburdened.

Conclusion:
After earning PMP I am much relived, I can see the fruits of hard work getting paid off. Whenever you say that you are PMP, there is a peer respect, because all of them know how much committed you need to be to earn this prestigious qualification. I now see what things at work do work and what not and how they are interrelated. PMP is not just a one-time process, you can apply this leanings in each every aspect of your life which you are doing unconsciously. Finally If I CAN DO IT ANY ONE CAN. You just need to remove the mental block and open up and think more in terms with best practices put forward by PMBOK, and your personal commitment.

Brief Profile: 
I am Aswin Krishnan H and am a Project Manager with Hewlett-Packard, India. I have 9 years of experience in Telecom, Retail and Security Domain with .NET Platform. 

*******

Aswin’s online PMP credential is available at PMI’s online credential registry.


I am thankful to Aswin for sharing his journey in achieving the PMP certification. I believe it will help you – the PMP aspirant – to have your own. 


Book Available for PMP Exam:

You may also like:


Saturday, November 07, 2015

PMI-ACP Prep: Agile Scrum - Sprint I/O (Inputs and Outputs)


Takeaway: At the heart of Scrum is Sprint, but the heartbeat of Scrum development is the Cadence. Cadence is developed when you have regular Scrum Planning meetings, Sprint retrospectives, Daily Scrums, Sprint reviews and you keep on delivering releasable and usable versions of the product. Key here is delivering working product of highest value to the customer – one of the cornerstones of Agile Manifesto, i.e., Working Software or Product. As cadence is important, so are the ceremonies (or events) of Scrum, as they build the cadence.

Hence it is important to know the events of Sprint and what are the inputs and outputs (I/O) of those events. In this post, I have not taken the various tools - such as task board, online spreadsheet, electronic tools and estimation techniques – such as planning poker, T-shirt size estimation. They tend to vary a lot from team to team.

There are 4 events (or ceremonies) in Scrum.
  • Sprint Planning
  • Daily Scrum
  • Sprint Review
  • Sprint Retrospective
The inputs and outputs, for the events, are as follows. 

Event – 1: Sprint Planning


Sprint Planning I/O
When? Happens after the Sprint review of the previous sprint, but before the first Daily Scrum of the current Sprint.
Who? The participants are: Product Owner, Development Team and Scrum Master
Others, e.g., subject matter experts or domain specialists can be invited into this meeting.
How Long? Timeboxed to a maximum of 8 hours for 4 weeks Sprint. Length will be less for shorter Sprints, e.g., 4 hours for 2 weeks Sprint.
What For? Sprint planning, as the name tells, plans for the work and forecasts the functionality to be developed during the Sprint.

Sprint Planning Inputs:
  • Refined product backlog: Product backlog, before presented in the Scrum planning, has to be refined (also referred as backlog grooming) by the Product Owner. Refining means having fine grained items ordered on top of the Product Backlog with ID, description, estimation, and value.  
  • Projected Team Capacity: It is a simple calculation considering the length of the Sprint, number of development members (and sometimes availability of the team members)
  • Projected Velocity: It is the past performance of the team. It is kind of the yesterday’s weather. It may or may not be available, e.g., for the 1st Sprint, it won’t be available.
  • Definition of Ready: I am taking this term "Ready" from the Scrum Guide, 2013. Ready means the story that can be done by Development Team in one Sprint are pulled from the Product Backlog to Sprint Backlog.
  • Key Stakeholders: Subject matter experts or domain specialists can be invited into this meeting among others (as needed).
Sprint Planning Outputs:
  • Updated Product Backlog: As the items are pulled into the Sprint backlog, there will be discussion on the product backlog items – some of the product backlog items are likely to be updated.
  • Sprint Goal: It has the objective that will be met in the current Sprint. Should be in terms of business value to be delivered.
  • Sprint Backlog: It has the forecasted product backlog items that will be delivered in the current Sprint. It also has the plan for delivering the work items, in decomposed form, to have the product increment.
  • Sprint Review Date: This is the demo date. Sprint gives the potentially releasable version of the product. On the demo date, the product increment is demonstrated.
  • Estimated Velocity: After development team takes up the product items that can be done in this Sprint, the estimated velocity is known.
  • Development Activities: The product backlog items are broken down (or decomposed) into development tasks (or activities) by team members. They can take help of technical specialists or SMEs who are invited to the meeting. 
  • Definition of Done: A checklist of items when the product backlog items selected into the Sprint Backlog will be considered complete.

Event – 2: Daily Scrum

Daily Scrum I/O
When? Happens daily after the Sprint planning. 
Who? The participants are: Development Team and Scrum Master, Product Owner 
How Long? Timeboxed to 15 minutes a day. 
What For? Inspect progress towards the Sprint goal; Inspect progress towards work being completed from the Sprint backlog; Synchronization; Communication

Daily Scrum Inputs:
  • Sprint Backlog: See Scrum Planning I/O. Sprint backlog is a plan which has enough details that helps team to understand the progress during the Daily Scrums. 
  • Spring Goal: The 3 questions (yesterday’s work, today’s work, and impediments) that are asked in Daily Scrum have to be aligned towards the Sprint Goal. 
  • Development Activities: See Development Activities input in Sprint Planning.
  • Impediments: Issues which are preventing the team members from executing their work.
Daily Scrum Outputs:
  • Updated Sprint Backlog: Daily scrum helps in inspection, planning, adaption for the next 24 hours. If any new work is needed, the Sprint Backlog is updated. Sprint backlog is also updated when work is completed.
  • Development Activities: The development activities are updated. Estimation for them may also change. 
  • Impediment Backlog: Not all issues can be resolved immediately, after the Daily Scrum. Impediment Backlog helps here to keep track of the issues when raised in Daily Scrum. It has to be tracked and resolved by the Scrum Master.
To have proper utilization of time (remember - 15 mins!) revised estimations or updating of tasks can be done immediately after the Daily Scrum. 


Event – 3: Sprint Review

Sprint Review I/O

When? Happens at the end of the Sprint, and before the next Sprint Planning.
Who? The participants are: Product Owner, Development Team, Scrum Master and also Key Stakeholders
How Long? Timeboxed to 4 hours for 4 weeks of Sprint. Length will be less for shorter Sprints, e.g., 2 hours for 2 weeks Sprint 
What For? To inspect the product increment and adapt the product backlog. 

Sprint Review Inputs:
  • Product Backlog: Product backlog items which are “Done” and “Not Done” in this Sprint are explained by the Product Owner
  • Product Increment: A potentially releasable version of the product developed by the Development team. It is the combination of all product backlog items completed in the current Sprint and value of increment of all previous Sprints. 
  • Sprint Goal: See Sprint Planning I/O.
  • Sprint Backlog: See Sprint Planning I/O.
  • Definition of Done: See Sprint Planning I/O. 
  • Business Conditions: I am taking this as an umbrella area - for market conditions, environmental conditions, new or changed business condition, new opportunities etc. - based on which the Product Backlog is revised.
Sprint Review Outputs:
  • Revised Product Backlog: It will have probable product backlog items for the next Sprint.
  • Inspected Product Increment: The product increment demonstrated by the Development to the key stakeholders. 
  • Completion Date Forecast: Product Owner gives the likely completion date based on progress done to date. This is mostly done for the upcoming release.
  • Actual Velocity: Shows the actual velocity of the Scrum team, i.e., taking up the items actually done in this Sprint. Estimated Velocity and Actual Velocity help in final updates to the Burn-down chart.

Event – 4: Sprint Retrospective

Sprint Retrospective I/O
When? Happens at the end of the Sprint, but before the next Sprint Planning.
Who? The participants are: Product Owner, Development Team and Scrum Master
How Long? Timeboxed to 3 hours for 4 weeks Sprint. Length will be less for shorter Sprints, e.g., 90 minutes for 2 weeks Sprint.
What For? For the Scrum team to inspect itself. A plan is created for improvements that can be undertaken in the next Sprint. 

Sprint Retrospective Inputs:
  • Definition of Done: See Sprint Review I/O
  • Sprint Backlog: See Sprint Planning I/O
  • Spring Goal: See Sprint Planning I/O
Sprint Retrospective Inputs:
  • Updated Definition of Done: Scrum team can plan ways to update the Definition of Done, e.g., stronger criteria for quality. 
  • Improvement Plan: Improvements are identified in the retrospective and a plan is created to implement those improvements.

Saturday, October 31, 2015

PMI-ACP Prep: Scrum and Kanban – Similarities and Differences



Takeaway: Scrum has seen wide adoption in the agile world. In recent years, Kanban, a mechanism taken from Toyota Production System (TPS), has been gaining popularity. Scrum Alliance's state of scrum report 2015 states that 42% respondents use Scrum exclusively and 43% combines Scrum with Kanban. Also, in the new edition of PMI's Agile Certified Practitioner (ACP) exam from 2015, Kanban has been emphasized. In this post, I seek to outline the various similarities and difference between Scrum and Kanban. 

In my PMI-ACP and other Agile related sessions, I get a number of questions on Kanban. In fact, in my earlier post on PMI-ACP new exam, I wrote:
“In past few years, a trend has been visible: Scrum is the most used one; Kanban is being used more now; however, organizations mostly follow their way of Agile implementation. The last one is interesting! Few follow Agile or Scrum or Kanban practices by the book per se, rather it is mostly customized as per the need of the organization.”
The scrum report of 2015 shows some interesting data. Though it does not show how many use “only” Kanban (logically it would not, as the report is for Scrum), I believe many organizations use Kanban while going for Agile implementation.

Data Source – State of Scrum Report, 2015 from ScrumAlliance

So, what are Kanban and Scrum?
Complete description of them is beyond the scope of this article. I’ll provide a brief summary.
Kanban is a Japanese term taken from TPS, which means “visual card” or “signaling card” or “signboard”.  Toyota used Kanban cards to trigger pull and limit the amount of work under progress. There are 3 key principles of Kanban: [v.i.z] visualize the workflow, limit work in progress (WIP) and manage the workflow. There are some more principles, which have been derived by proponents of Kanban. However, the mentioned three are the key ones. 

Scrum, which is by far the most used framework, provides an iterative and incremental approach to product development. In every iteration - called sprint – a set of features are taken up by team and then delivered at the end of iteration. Well, to be precise, "potentially releasable" version of the product. There are certain key ceremonies which one has to follow and there are prescribed artifacts which should be available. 

Now, let us look at the similarities and differences. I have seen similarities and differences help. Hence, taking that approach. The list, of course, is not exhaustive. There can be others. 

Similarities: Scrum and Kanban

Differences: Scrum and Kanban

As noted in my earlier post, PMI-ACP exam has changed, there has been certain focus on Kanban. 
“For the new PMI-ACP exam, the reference book list has changed and quite a few new book have been added – especially for Kanban – perhaps matching the trends in the Agile world.” 
It is important that you understand the concepts of both Scrum and Kanban to do well in the exam. Hence this post and believe it will help in your preparation.