Project Management

Deliverables diagram saves million meetings

In this article I am going to talk about the deliverables diagram of a project.  The facts that I am going to present here will be familiar for most of the readers. This is all about project life-cycle: initiating, planning, executing, controlling and closing.

The deliverables diagram will help the whole team to identify the inputs to each phase and what are the expected outputs from each phase and I will highlight the importance of each of these artifacts against the project phases.



Key ingredients to build a product road map

Why do we need a good product road map strategy? And what are the ingredients that is required to create a proper road map? In today s’ competitive environment new products are introduced to the market every day. We can’t sit back and relax. Product managers, sales and marketing team, other interested parties in the company should work together to meet the customer demands. In this article I am trying to find out what are the key ingredients to create an effective product road map.

So who creates the road map? Ideally the Product managers need to build the road map at least 3 to 6 months ahead. Make sure that this road map is shared among all the stakeholders and better if you can display it to the whole company. They need to visualize the new features before the customers do. Also these features need to be useful to the end users. If you include any new feature in your road-map that is not usable or in other words does not bring value to the end users then it is waste of time and money. So PMs need to be carefully plan the road map. Most importantly they need to visit the road-map at least twice a week. Alter it according to the changing market needs, because we all know that the market is changing all the time.

Reducing the Bug count in your backlog

When there is a huge backlog with a combination of both new features and bugs, you will have a pretty hard time control this. It is really difficult when you develop products and everyday this bug count will grow when customer using it. Same for the new feature list. So what can we do to control this situation?
Following are new steps that you can follow in terms of Agile Project Management.

  • Take a count of new features and bugs. So that you know how much bugs and features are there in the backlog. If you are using physical boards display these numbers so that everyone in the team knows this.
  • Then plan for the first sprint with new features. Priorities the new features and create the sprint backlog and start working on it.
  • Remember to keep some story points to deal with “New Issues”. For example, if the bug count is 200 then if it becomes, 201 then you need to solve the new issue immediately keeping the bug count under control. Attend to the new issues, even if the whole team has to look into that, let them fix the new issue.
  • Remember to keep some story points to deal with “New Issues”. For example, if the bug count is 200 then if it becomes, 201 then you need to solve the new issue immediately keeping the bug count under control. Attend to the new issues, even if the whole team has to look into that, let them fix the new issue.
  • As the Project Manager you need to look into whether this has any impact on the sprint goals. If the delay has an impact on the sprint goal and then cancel the sprint, start a new sprint after completing the issue. Remember the important thing out here is to control the bug count.
  • Also as the Project Manager you may need to inform the interested parties about the delay and make sure to convince them that how important it is to keep the bug count under control.
  • Do this for about maximum of two sprints. After that you can include about 5 bugs in the 4th sprint and fix them. By the time the number of bugs in the backlog will have 195. Keep it under control, don’t let it grow to 196.
  • During sprint planning sessions make sure that you include some bugs, so the number of bugs will reduce when time progresses.

Again, you and your team must be committed to complete the new issues when they are reported. Don’t leave any new issues unattended. Even if you have to give proper explanation to the reporting party and close it immediately. This way you can control the bugs, plus add new features to the product. Same will apply for project development as well.

Risk management and Impediments

When we manage projects with Agile concepts, we normally don’t give much weight to the traditional project management concept of Risk Management. Reason for this is in Agile terms we tend to deal the risks as they occur with impediments during the sprint itself. Besides when we develop software in an iterative manner, and delivering working software at the end of each sprint for the client, makes the possibility of risk considerably in a lower range.
Normally what I encourage the scrum master to maintain an impediment backlog for the sprint, where they have to clear the impediments during the sprint itself. By this way we are dealing with various risk as they occur. This doesn’t mean that we can ignore risk because we are unaware until the risk or the impediment occurs.
As Mike Cohn suggest in his article (Managing Risk on Agile Projects with the Risk Burndown Chart) I find it really easy and it is an effective way of dealing with risk in Agile projects. We normally spend time during the sprint planning meeting to identify any possible risk that could occur, such as technical difficulties that could occur during implementation of certain user stories, setting up server instances for development purposes, or it could be issues with shared resources being not available, such as system administrators, database administrators, etc. One major risk that we need to tackle is to provide requirement clarifications as soon as possible. Failing to do so may result in on hold and incomplete user stories by the end of the sprint.

How do you estimate projects with fixed dead line and must have features using Agile.

This is a scenario where no project manager would like to be. It is in fact a bad dream. At the beginning you can’t predict the rate of bugs and rework together with the change requests. These critical items that have dramatic effects on the estimates you give. In this article I am going to discuss the best practices that Agile estimation provides for us to effectively deal with this type of projects. I will take an example application to describe this scenario.

The Project: Migrating all the manual work done by a legal firm to Office 365. Basically you need to move all the operations to the Office Cloud, because the particular firm doesn’t like to maintain hardware and the staff want to access to the critical information when they are in and out of the office. All the clerks uses laptops and the legal offices and lawyers use hand held mobile devices such as IPads and Android devices. The firm handles many clients daily and they need an effective way to collaborate and communicate. Technical consultant team provided the best solution with office 365 because it provide all the needs that the user wanted. They also wants to share information with all the legal officers and lawyers. According to the agreement there is a fine if we fail to deliver the project on time, there is a fine for each delayed date. Let’s say it is $1000.00 per day. So if we delay the project by 10 days, the fine would be $10000.00.

Mapping Agile Project Management to phases of Traditional Project Management

In this article I am going to talk about how we could map agile concept in a traditional project management phases. This is highly useful when moving from traditional methods to agile. So first of all what are the phases of traditional project management.

Initiation: During the initiation phase even before getting the team and infrastructure, you need to get the business case ready. You need to convince the project board about the ROI. i.e. whether this project worth of investing money and knowledge. Once the project board is presented with what the project is going to do to the business and when they approves it, you can look into identifying the budget, the team, the infrastructure, etc.

Planning: In this phase we prepare the schedule, resource planning, preparation of the firm budget and a cash flow plan, resource plan, risk management plan, etc. Also we can finalize the team and the infrastructure required. You may want to plan for change control management, issue management, etc. as well.

Execution: So after all the planning is done we are ready to roll out with the execution. During this phase you need to monitor and control various activities such as development, testing, change control, release management, etc. and ensure that the team is on track and delivering the requirements according to the plan.

Closing: At the end of the project you need to package up everything and ship the product to the user. You also can allocate time for end user training, preparation of user manuals, UAT, etc.
I am sure that all the audience are aware of the activities in detail which are executed during these phases. Here I have given a brief description. What my goal here is to discuss how agility can be implemented on top of these phases.

This is what I do. For me we have to do initiation and planning up to some extent before beginning. Remember doing agile is not just starting with it. You need to do some preliminary planning first. This will totally depends on the nature of the project. If your company is focusing on software products you may have to have product road map with several releases during the year. So if you want to get some new features done and some long hanging bugs fixed then initiate an internal project. You may want to get the involvement of the product managers and convince them about the priorities that you have set. You can use the planning phase to carry out traditional PM work as mentioned above.

Few tips on creating effective user story strategy

When we are practicing Agile, we don’t use comprehensive documentation, instead we create user stories. User stories are by definition a conversation between the user and the development team. Basically we convert the user requirements to User stories. So these requirements must fall into the INVEST acronym.


I – Independent: Should be able to execute it without any dependency to other features.
N – Negotiable: Requirements are not contracts or promises, because there are too many details to be discovered to actually understand the problem.
V – Valuable: Should be valuable to the end user, i.e. expressed in a way that is easily understandable by the end user.
E – Estimable: These are used in planning and if the team lacks the domain knowledge or if the item is too large to be estimated then it does not meet this criteria.
S – Sizable: The item should be easily fit into the coming up iteration. If it is too large to be included then it has to be broken down to much smaller items
T – Testable: Ability to define the acceptance criteria for the requirement.