Day: June 9, 2017

Agile Estimations – How to?

Agile Estimations – How to?

Planning Poker or Scrum Poker.

Estimating a project, in terms of cost and time is always a difficult task for all project managers.  A project manager who have completed a similar project, the estimation would be much easier than a fresh project manager who doesn’t have e a  previous domain experience. In Agile the solution for the problem is doing a Planning Poker or Scrum Poker.

Procedure

At the estimation meeting, each estimator is given one deck of the cards. All decks have identical sets of cards in them.

The meeting proceeds as follows:

  • A Moderator, who will not play, chairs the meeting.
  • The Product Manager provides a short overview of one user story to be estimated. The team is given an opportunity to ask questions and discuss to clarify assumptions and risks. A summary of the discussion is recorded by the Project Manager/Scum Master.
  • Each individual lays a card face down representing their estimate for the story. Units used vary – they can be days duration, ideal days or story points. During discussion, numbers must not be mentioned at all in relation to feature size to avoid anchoring.
  • Everyone calls their cards simultaneously by turning them over.
  • People with high estimates and low estimates are given a soap box to offer their justification for their estimate and then discussion continues.
  • Repeat the estimation process until a consensus is reached. The developer who was likely to own the deliverable has a large portion of the “consensus vote”, although the Moderator can negotiate the consensus.
  • To ensure that discussion is structured; the Moderator or the Project Manager may at any point turn over the egg timer and when it runs out all discussion must cease and another round of poker is played. The structure in the conversation is re-introduced by the soap boxes.

Procedure source: Wikipidia

Contingency Planning and Management – I should have known better

Contingency Planning and Management – I should have known better

Contingency Planning in IT projects 

Unexpected and unforeseen issues do happen in all projects.  To manage the  negative impacts,  Project Managers plan a contingency arrangement to complete the project on time and within the budget.

Why do we need a contingency plan. 

  • To finish a project on schedule and within budget
  • To avoid unnecessary pressure on other team members

How do we plan to face an emergency situation in IT projects

The first step in contingency planning is identifying the constraints in advance.  The probable constraints include

 Vendor Supply

This issue do happen if we depends on a third party on hardware supply or support on both hardware and software.

How to plan?

*Constantly keep in touch with the vendor directly or indirectly how well they are on their promise on delivery and provide feed backs and manage projects slightly according to the delivery schedule.

*Plan and identify and make arrangements in advance for an alternate supplier and their conditions.

Key Personnel:

Whole project delivery commonly depends on few key people in the project team.  They are mostly domain experts or senior developer or someone who already have a wide knowledge about a similar project or same project.  These people normally have multitasking skills and  often members of other projects as well. A sudden disappearance of these people from the project would significantly effect the outcome of the project. Having a plan in place to substitute an expert by assigning tasks to suitable staff is always a better management policy.

How to plan and Manage this situation?

Always find backup domain experts for consultation before the beginning of project.  To replace these key people normally need more headcounts with individual skills.  From the time of project planning, project managers do assign( most of the time confidentially) a replacement for all key positions called Plan B and ask for extra 20% staff  as float.