How To Manage Project Delays

Project delays are integral part of day to day deliveries, however not affordable.

Parkinson's Law, speaking to effort, tells us that "work expands to fill the space allotted".
Murphy's Law, speaking to uncertainty, tells us that "whatever can go wrong will go wrong, and most likely at the worst possible time".

Such realities are faced by all project managers. No matter how much time you have for a project, it will likely be consumed, and no matter how well you plan, eventually you will always be faced with the "unexpected".
So, if work always expands to fill the space (time) allotted, and whatever can go wrong will go wrong, the only thing you can do is to Be Prepared. 

This post will try to highlight few techniques to Prevent Delays (Before Delay Occurs) and Fix Delays(Post Delay Occurs).

Preventive: Technique to Prevent Delays:

Catch It Early & Track Vigilantly

• Unless you have some magic, ideal way to handle project delays is to predict them happening and countering whatever may be the cause, avoiding any interruption altogether.
• Keeping yourself constantly aware (Have Daily Team Meetings) of the project schedule and keeping in close contact with your team will enable you to notice a delay as soon as it happens.
• Keep a close eye on upcoming deadlines and priority assignments. If you notice that some deadlines are falling behind or a specific task is not as close to completion as it could be, ascertain what is causing the holdup and resolve it quickly to avoid any further setbacks.
• Keeping quick attention and prompt action will get the project back on track as close the original deadline as possible.

Prioritize

• Review tasks & priorities assigned to team members. 
• Project Risk are always high during the start.
• Thus always prioritize project assignments, moving any that are especially time sensitive to the top of the list. 

Record Changes or Scope Creep

• Obtain final requirements & get a sign-off on the functional specification before starting construction
• Never accept changes unless you have done a complete impact analysis on each of the baselines – Time/Cost/Quality
• The best way to do so is by creating a change control plan that outlines the proposed changes, review, approval and implementation.
• Any change impact causing project delays should advance project delivery timelines or reduce in scope.

Predictable Delays - Document Project Delays Risk & Have Mitigation Plan Ready:

• Predictable delays (those deemed likely by circumstance and experience) can be factored into the project via a documented risk management plan. 
• When Risk plan is prepared, risks can be identified and evaluated to determine probable delays, and potential mitigating action.
• If risk is realized, the risk management plan will provide a pre-planned course of action.

Un-Predictable Delays - Document Project Delays Risk & Have Contingency & Management Reserves Ready:

• Unexpected delays are those that were generally not foreseeable, and plan them in risk management plan to reserve Contingency & Management Reserves

Corrective: Technique to Fix Delays & Bring Back on Schedule:

Plan Additional Work / Resources

• Once you realize that there is a delay, organize a team meeting.
• Inform everyone working on the project about the delay, including details such as factors contributing to the holdup and how far it has set the project back.
• Ask for input and ideas on how to get back on schedule, and plan a course of action moving forward.
• Decide whether you need additional work from team members or supplementary resources are required.
• Also asking for volunteers who are willing to take on extra tasks as needed is advisable, as well.

Cut Any Fat (Lean Thinking)

• Determine whether there are any assignments that can be trimmed down or done away with completely.
• Scaling back on unnecessary tasks will not only get you closer to your schedule but also ensure that your team has the time needed to produce quality work.

Notify Stakeholders

• Keeping project stakeholders informed and up-to-date when there is a delay is a good practice.
• If there is a holdup, it is better for them to hear it from you than to get wind of it through the rumor mill.
• Your transparency will re-assure them that you are well aware of the causes of any project delays and that you have everything under control.
• At times, updating stakeholders on end date changes allows them to plan accordingly, as well.

Notify External Dev/Testing Teams

• Get in touch with external teams is also important.
• On the other hand, you might need to ask a contractor if they can have their part of the project completed even earlier in order to put other tasks on hold.
• You may need to let some of them know that you will not be needing their services until a later date (and save project cost), if their role in the project has been moved back due to the delays.
• Either way, keeping the lines of communication open can eliminate potential problems that would only cause more delays.

Finally, step away from the project briefly. Give yourself time to catch a breath and process all of the readjustments.
Then you can head back to the tasks at hand with renewed perspective and focus on what is yet to be completed.
Doing so ensures that you are able to give the project your full attention without risking the quality on which you have built your reputation.

Hope this helps!!!

Liked reference: https://www.ittoolkit.com/how-to-it/projects/manage-project-delays.html

Arun Manglick
(AWS-ASA, SAFe Agilist, PMP®, PMI-ACP®, PRINCE2® Practitioner, CSM®, MS-Project, CSSGB, ITIL V3, MCPD, MCTS)

How Project Manager Start/Manage Projects

Project managers need a broad range of skills. Here is the complete DNA/guide to know 
- How to Start a Project, 
- How to Execute Project and 
- How to Monitor and Control Project &
- How to Close the Project

Process Group Wise Details as below: 

1). Project Initiation - Link

• Understand Business Case
• Create Project Charter/ PID
• Formally Outline What/Why/Who, How & When
• Prepare Project Purpose/Objective/Business Case
• Prepare High Level Requirements
• Prepare High Level Estimates
• Prepare Conceptual Level Design
• Prepare High Level Initial Risk/Assumptions/Constraints/Dependencies
• Prepare Inclusion/Exclusion from Scope
• Project Manager Selection
• Identify Stakeholders
• Specifically define what stakeholders need and expect from the project
• Formally present the Project Charter Details and Gain Acceptance with Business for further Planning & Execution.

2). Project Planning

• Collect Project Requirements/Scope:
• Detailed Requirement Gathering – Functional Specifications & Use Cases
• Define Scope & Scope Breakdown(WBS)
• Define Activities & Micro Estimation 
• Estimate Activity Durations
• Estimate Resources – Same 
• Determine Project Cost/Budget – 
• Define Project Cost & Budget – DRCP
• Consider a variety of cost alternatives when developing my original project budget plan.
• Consider & include extra funds in the budget and hope that project run under cost at the end
• Create Project Plan & Project Schedule
• Formally create a Project Plan having all the details - Project Background, Objectives, Scope, Constraints, Assumptions, Dependencies & Impacts, Issues & Risks, Methodologies & Strategy, Controls - Scope/Time/Cost/Quality, Resources, Communications, Schedule of delivery, Team Charter, Performance Measurement Metrics, Benefits Realization.
• Prepare a specific timeline and sequence of activities, and use this schedule to manage the overall project to ensure its timely completion
• Plan Quality
• Identifying Quality Requirements and Quality Standards for the project and product, and documenting how the project will demonstrate compliance – i.e. What work will be done to meet the standards. 
• Identify Risk
• Identify as many potential project risks, their Probability/Impact, Response Strategies, Mitigation Plan, Contingency Plan/Reserve, Management Reserve, Residual Risk, Secondary Risk etc.
• Plan Approval
• Formally discuss Project Plan, Estimates, Schedules, Delivery Timelines, Project Status Reports Formats, Project Plan with Business before moving to Execution Phase.

3). Project Execution

• Execute Project According to Project Plan & Project Schedule
• Communicate what needs to be done by what deadline, and expect the people to whom I assign the work to be responsible for breaking down the work packages into smaller and more manageable pieces
• Outline clear expectations for the project team, and I manage their individual and collective performance as part of the overall project evaluation process
• Give people a deadline to complete their project work, and then I expect them to coordinate with others if and when they need to.
• Conduct Daily Team Meetings to tract work and Impediments
• Plan Interim Demos and Release and Gain Early Acceptance with Business
• Handle Change Request, if any
• Take Preventive/Corrective Measures to Avoid/Fix Project Delays - Link
• Routinely monitor and reevaluate significant risks as the project continues
• Keep all project stakeholders informed and up-to-date with regular meetings and distribution of all performance reports, status changes, and other project documents.

4). Project Monitoring

• Monitor & Control Project Delays & Schedule
• Monitor & Control Project Scope, Cost & Budget
• Monitor & Control Project Risks
• Monitor & Control Third Party Vendors, if any

4). Project Closure

• Gain formal acceptance of the project/product
• Create Lessons Learned
• Handover, if any

Knowledge Area Wise Details as below: 

Project Integration 

• Develop a solid understanding of the project's goals.
• Start by producing a Business Requirements Analysis, and then develop a comprehensive Project Initiation Document, which covers the basic project needs and outcomes, so that everyone can understand the project's goals. 
• To prepare this critical, high-level document, you need to understand the phases and processes of project management. This overview will help you become better prepared for what's ahead.

Scope Management 

• Projects have a nasty habit of expanding as they go along, making it impossible to hit deadlines. To control this “scope creep,” it's essential to define the scope at the very start of your project based on the Business Requirements Analysis, and then manage it closely against this signed-off definition. 
• For more on how to do this, see our article on scope control.

Time/Schedule Management

• A project's scope can easily grow, and so can the time needed to complete it. 
• For a project to be completed successfully, despite all of the unknowns, it's important to clearly define the sequence of activities, estimate the time needed for each one, and build in sufficient contingency time to allow for the unexpected. 
• With this information, you can develop a Project Schedule and then begin breaking it down into very specific pieces of work using a Work Breakdown Structure. 
• A schedule often isn't enough. To keep track of the various activities, Gantt Charts and Critical Path Analysis are often helpful.

Cost Management 

• To determine what a project will cost, you must be systematic with your estimating, budgeting, and controlling. 
• Also, be aware that many project decisions will have an impact on cost. 

Quality Management 

• To achieve quality, ensure that you actively manage project benefits. By continuously referring to the benefits that the project will provide, you keep client quality at the forefront – and you won't waste precious time and resources trying to achieve an inappropriate level of quality. 
• An effective project manager knows the importance of checking that project outcomes are consistent with needs. The Deming Cycle (Plan-Do-Check-Act) and Business Testing are important tools for this, as they both force you to consider the needs of the end users. 

HR/People Management 

• Right mix of interpersonal and political skills is just as important as the right technical skills. 
• To help your new team start working together effectively as soon as possible, develop a Team Charter and outline performance expectations. 
• Use well-informed task allocation and appropriate team management skills to keep the project team on track and working productively. 
• And be prepared to help people through the Forming, Storming, Norming and Performing stages that so many teams go through.

Communication

• As with most situations, effective project communication means communicating with the right people at the right time and in the right way. 
• To do this, Stakeholder Management is essential. When you analyze your stakeholders, you identify who must be kept informed in full, and who needs less intensive communication. This can save you a lot of time, and helps you maintain good relationships with people involved in the project.
• Project Dashboards are great for presenting project updates in a way that people can quickly understand. For longer projects that require periodic status reports, Milestone Reporting is effective for capturing the essentials of a project's status.

Risk Management 

• Project managers must understand which of the risks to their plans are significant. An Impact/Probability Chart will help with this. 
• From there, develop a plan for monitoring and controlling the major risks involved in your project. 
• Using your Risk Analysis, develop options to reduce risks, prepare Contingency Plans, and decide who is responsible for which parts of risk response.

Project Procurement 

• Unless your project is in-house, external suppliers will generally have a large impact on your costs. Suppliers will also affect whether the project delivers on time and to specification. 
• Take the time to define your needs in a Request for Proposal document, and then use an appropriate Procurement Management approach to select the best supplier. 

Hope this helps.

Arun Manglick

(AWS-ASA, SAFe Agilist, PMP®, PMI-ACP®, PRINCE2® Practitioner, CSM®, MS-Project, CSSGB, ITIL V3, MCPD, MCTS)

What should be in a Project Plan?

How to Write a Successful Project Plan?

 

The Project Plan is one of the most important and useful documents in your toolkit, and should be referred to and updated throughout the project lifecycle.

Its initial purpose is to kick-start the project by convincing the decision makers that the project is viable and will meet their needs and timeframes / budgets / expectations.

If the Project Plan is poorly written or contains insufficient detail, the project may not even get past this first decision gate and may never actually get off the ground.

Don't confuse a Project Plan with a Project Schedule. A schedule is merely a component of a Project Plan, and usually takes the form of a timeline / GANTT chart depicting tasks vs. timeline.

A project schedule is a vital tool and should complement the project plan. Larger Project Plans contain several schedules, normally as appendices, that are referred to throughout the document.

Such schedules would include an overall timeline, a test schedule, an implementation schedule, the critical path analysis, a resource allocation schedule....etc 

What should be in a Project Plan?

The Project Plan serves as a roadmap for the entire project team providing guidance on the priority of activities, the scope of work, the methodologies and governance to be used, who the stakeholders are, the broad strategy to take, how costs and people will be managed, the quality standards in the project, how the project will communicate with stakeholders, how performance and benefits will be measured...etc

The main areas you need to cover in your plan include:

• Overview
• Project Background
• Objectives & Scope
• Constraints & Assumptions
• Dependencies & Impact
• Issues & Risks
• Methodologies & Strategy
• Controls - Scope, Time, Cost, Quality, Resources
• Communications
• Impacted Business Areas 
• Definitions and Acronyms 
• Project Related:
• Project Lifecyle
• Traceability Approach
• Change and Issue Management Approach 
• Schedule of delivery
• Milestones
• Budget
• CAR Approach
• DAR Approach
• Project Team
• Project Organization
• Project Team Structure
• Roles and Responsibilities          
• Staffing & Training               
• Project Control
• Process Deviations    
• Project Data Management         
• Project Metrics 
• Performance Measurement
• Project Monitoring and Control
• Quality Objectives and Metrics 
• Project Communication
• Stakeholder and User Involvement
• Project Governance
• Project Status Reports & Frequency
• Project Environment
• Infrastructure, Critical Computer Resources and Facilities
• Hardware and Software Environment             
• Testing & Training    
• End User Training          
• Deployment Strategy and Approach       
• Training Approach          

As you can see there are many elements to a Project Plan, and some of the larger plans can stretch well over a hundred pages. This makes structuring your document all the more important.

A consistent format with a logical order (as below) and clear headings will allow your readers to quickly navigate through the document and get to the details that are important to them.

Visit the link: http://www.pmmilestone.biz/ to get a Complete Set of 7000 plus Project Management and Business Templates, Plans, Tools and Forms with detailed guides and examples.

And everything a project manager needs to deliver a successful project. And these templates Can Increase the Efficiency of Project Managers to Meet the Project.

Reference: https://www.linkedin.com/groups/37888/37888-6174499681943437315

Thanks & Regards,

Arun Manglick,

Why Estimate In Story Points

This post outlines the key points in favor of estimating user stories in story points. These include:

• Story points help drive cross-functional behavior
• Story point estimates do not decay
• Story points are a pure measure of size
• Estimating in story points is typically faster
• My ideal days are not your ideal days

  

Story points help drive cross-functional behavior

Agile teams include members from all disciplines necessary to build the product, including programmers, testers, product managers, usability designers, analysts, database engineers, and so on.

Estimate in story point presents a single number that represents all of the work for the whole team. Thus Estimating in story points can help teams learn to work cross-functionally.

On the other hand Estimating ideal days,  often involves specialty groups estimating how long "their part" of a story will take and then summing these sub-estimates.

For example, the programmers may conclude that they need three ideal days, the database engineer needs one, and the tester needs two. An estimate of six ideal days is then assigned to the story.

This small difference in how the discussions about a story take place (to provide a single story point) have an ongoing impact on how the story is developed.

Story Point Estimates Do Not Decay Or Has Longer Shelf Life

An estimate expressed in story points has a longer shelf life than an estimate in ideal days.

An estimate in ideal days can change based on the team's experience with the technology, the domain, and themselves, among other factors.

To see why, suppose a programmer is learning a new language and is asked how long it will take to program a small application. His answer may be five days.

Now, jump forward a few months and ask the same programmer how long it will take to develop an application that is of exactly the same size and complexity.

His answer may be one day because he has become more skilled in the language.

We have a problem now because at two different times, even the applications are exactly the same size, yet they have been estimated differently.

We would like to think that measuring velocity over time would correct or account for this problem. It won't. Instead, we'll see a consistent velocity even though more work is being done. Suppose this programmer is the only person

on the team and that he is working in one week iterations. The first time he develops the application, he has estimated it will take five ideal days. Let's suppose he's in an environment where a calendar day equals an ideal day. He then starts this application on the first day of the iteration and finishes it on the fifth. He has a velocity of five for that iteration. Then, a few months later, because he estimates a similarly-sized application as one ideal day, he will complete five of them in an iteration. His velocity is again five, even though he did five times as much as work as before.

For some projects, especially those adopting new technologies or on which the team is new to the domain, this can be a consideration. Note that both story point and ideal day estimates will need to be updated if the size of an effort changes based on the development of a framework, for example. However, only ideal day estimates need to change when the team the team becomes better at something.

Story Points Are a Pure Measure Of Size

Story points are a pure measure of size. Ideal days are not. Ideal days may be used as a measure of size, but with some deficiencies.

As noted in the preceding section, an estimate in ideal days will change as a developer's proficiency changes. This does not happen with story points—the size is what it is and doesn't change. That is a desirable attribute of any measure of size.

Estimating in Story Points Is Typically Faster

Teams that estimate in story points seem to do so more quickly than teams that estimate in ideal days.

In order to estimate many stories it is necessary to have a very high-level design discussion about the story: Would we implement this in  the database? Can we re-use the user interface? How will this impact the middle tier? are all questions that come up at one time or another. My experience is that teams estimating in ideal days have a tendency to take these discussions a little deeper than do teams estimating in story points.

The difference is presumably because when estimating in ideal days it is easier to  think about the individual tasks necessary to develop a story, rather than thinking in terms of the size of the story relative to other stories.

My Ideal Days Are Not Your Ideal Days

Suppose two runners, one fast and one slow, are standing at the start of a trail. Each can see the whole course of the trail and they can agree that it is 1 kilometer.

They can compare it to another trail they've each run and agree that it is about half the length of that other trail. Their discussions of trail size (really distance in this case) are meaningful.

Suppose instead of discussing the length of the trails these two runners discussed the time it took to run the trails. The fast runner might say, "This is a six minute trail," to which the slow runner would respond, "No, it's at least a ten minute trail." Each would be right, of course, but they would have no way of settling their differences other than agreeing to always discuss trails in terms of how long one of them (or some other runner) would take to run the trail.

This same problem exists with ideal days. You may think you can completely  develop a particular user story in three ideal days. I think I can do it in five days. We're both probably right. How can we come to an agreement? We might choose to put your estimate on it because we think you'll be the one to do the work. But that might be a mistake because by the time we actually do the work you may be too busy and  someone else maybe doing it. And I'll be late because it's estimated at three days for you but will take me five.

What most teams do is ignore the issue. This is acceptable if all developers are of approximately the same skill or if programmers always work in pairs, which helps balance out extreme differences in productivity.

http://www.deltamatrix.com/agile-estimation

Happy Blogging!!!!

Regards,

Arun Manglick

---

本メールおよび添付ファイルは、機密情報を含んでいる可能性があります。そのため、宛先人以外の方による利用は認められておりません。宛先人以外の方による本メールの公表・複写・転用等は厳禁であり、違法となることがあります。万が一、本メールを宛先人以外の方が受信された場合は、お手数ですが、直ちに発信人にお知らせいただくとともに、本メールを削除するようお願いいたします。

The contents of this email and any attachments may include confidential information. Therefore, they may not be disclosed to, used by, or copied in any way by anyone other than the intended recipient and any such disclosure, use or copy can be treated as illegal. In the case this email is sent to you in error, please inform the sender and delete this email.

Risk Management in Agile

Primarily Risk is something that may occur and cause unexpected or unanticipated outcomes.

Traditional project management applies full-blown Risk Management techniques and recommend a full-blown risk register to monitor for managing and controlling risks.

However there is no definite consensus on the need for risk management within the Agile method.

In many of my classes, participants ask how Scrum and Agile address risk management. Some are concerned that Agile or Scrum completely ignore risk management.

Here is the rationale. First, a great deal of explicit risk management becomes unnecessary when a project uses an agile approach. The short iterations, single-minded focus on working software, heavy emphasis on automated tests, and frequent customer deliveries help teams avoid the biggest risk most projects face—that of eventually delivering nothing. So, it is not surprising that many agile projects forgo any form of explicit risk management

This has led many to believe that risk management is irrelevant in an iterative model, rather manage risk & issues through the natural sprint progression.

Because of this, managing risks may not seem to fit naturally into the Agile context.

However risk can be undertaken in Agile also without any formal risk management, may be preferably thru simple techniques: 

• Simple Risk Register
• Simple Risk Burn-down chart

 Simple Risk Register

Below are the attributes to keep risk monitoring thru simple risk register.

Risk register must be made available for the team so that it can be managed and monitored collaboratively. 

• Description of risk: A one- or two-line overview of the risk. It should be simple and easy to comprehend.
• Date identified: Date when the risk was identified.
• Likelihood: Estimated probability of occurrence of the risk.
• Severity: The severity of the risk is assessed based on impact of the undesired outcome.
• Priority (optional): This could be either given an independent value or set as a product of likelihood and severity (above). A high-severity risk with a high likelihood should receive more importance than a high-severity risk with a low likelihood.
• Owner: The person who manages, controls, and takes action in response to the risk.
• Action: The response defined to manage/control the risk.
• Status: Indicates whether the risk is open or closed or being monitored.

At every sprint meeting, the risk register must be reviewed and updated with any new information obtained over the sprint.

This way risk management becomes an integral part of Agile.

Risk Burn-down Chart

Another interesting technique, to managed and controlled risk is thru Risk Burn-down Chart (Originally introduced by John Brothers in The Agile Times in 2004)

In essence, the burn-down chart represents the status of the risk across the iterations.

Similar to other burn-down charts, the ideal burn-down would be a linear decrease of consolidated risk exposure over the sprints.

Risk Exposure is collected into a table similar to a risk register as below. 

• Risk: Description of the risk in a few lines.
• Probability: Likelihood of the risk.
• Size of loss: Amount of time lost should the risk occur. This could be represented in days or story points.
• Exposure: This is computed as a product of the probability and size of loss (above).

 An example is shown below. The consolidated risk exposure is shown in the final row of the risk register.

This consolidated risk register is reevaluated at every sprint meeting; its values are adjusted based on the current assessment of the existing and new risks.

Summary:

Above are two of the bare-minimum approaches that are effective in Agile. They're simple to manage and align with the iterative process.

Adopting one of these is critical to having a proactive risk management approach.

Regards,

Arun Manglick

Agile Estimation

First time, putting this link directly. as this post does not require references from multiple sources .. 

http://www.deltamatrix.com/agile-estimation


Regards,
Arun Manglick

Sprint Retrospective Meeting - Facts & Rules

Source:  Agile Project Management with Scrum by Ken Schwaber

Duration:

1.     Time-boxed to 03 Hours (Three Hrs).

2.     Occurs after Sprint Review & Before Next Sprint Planning meeting.

  

Attendees:

3.     Team, Scrum Master, and Product Owner.

4.     The Product Owner is optional

 Retrospective Procedure

5.     All Team members answer two questions:

a.     What went well during the last Sprint?

b.     What could be improved in the next Sprint?

6.     Also team members can think on four Short Subjects:

a.     Start Doing

b.     Stop Doing

c.     Do More

d.     Do Less

7.     The Scrum Master writes down the Team’s answers in summary form.

8.     Scrum Master does not provide answers, but facilitate the Team’s search for better ways for the Scrum process to work for it.

Action Items – At The End

9.     The Team prioritizes in which order it wants to talk about the potential improvements.

10.   Actionable items that can be added to the next Sprint should be devised as high-priority non-functional Product Backlog.

More Details On Retrospective

11.   Type of Retrospectives

a.     Iteration Retrospective

b.     Release Retrospective

c.     Project Retrospective

d.     Surprise Retrospective

12.   Retrospectives Improvements: Retrospective offers multiple improvements.

a.     Improved Productivity

b.     Improved Capability

c.     Improved Quality

d.     Improved Capacity

13.   Steps to Conduct Retrospectives

a.     Set the Stage

In this step, aim at creating an atmosphere where people feel comfortable speaking about things that may not have gone well on the project.

Few techniques:

·         Check-In – Ask everyone to summarize in one-two words what they hope to get from retrospectives.

·         Focus On/Focus Off

·         ESVP - Explorers, Shoppers, Vacationers, Prisoners

·         Working Agreements

b.     Gather Data

Create a shared picture of what happened during the iteration.

Few techniques:

·         Timeline

·         Triple Nickels – Top Five Ideas, Elaborated By Five Groups, Five Times

·         Mad, Sad, Glad

·         Local Strength

·         Satisfaction Histograms

·         Team Radar

·         Like to Like

c.     Generate Insights

This step involves driving meaning insights from the gathered data in previous step and make sense out of it.

Activities done in this step help team interpret and understand implications of the issues before then move on to solving them.

Few techniques:

·         Brainstorming

·         Five Whys

·         Fishbone

·         Prioritize with Dots

·         Identify Themes

d.     Decide What To do

                        In this step, team will decide what they will change and how they will behave differently.

Few techniques:

·         Short Subjects –

1.     What Went Well,

2.     Do differently Next time

3.     Keep, Drop, Add

4.    Start Doing, Stop Doing, Do More, Do Less

·         SMART Goals

·         Retrospective Planning Games

·         Circle Of Questions

e.     Close Retrospective

                        Here team summarizes:

·         What the team decided to keep

·         What to change

·         What we are thankful for

·         Where we can use our time going forward

·         Express Appreciation to each other

Few techniques:

·         Plus/Delta

·         Helped, Hindered, Hypothesis

·         ROTI (Return on Time Invested)

·         Appreciations

Keep Blogging...

Regards,

Arun Manglick