Category: Project Management

Software Estimation Plan

Microsoft Excel IconIn software development, planning is a necessary component regardless of whether one takes a traditional waterfall methodology or adopts a more agile mindset, such as SCRUM. As a project manager or scrum master, you often have to estimate how long a software release or product will take to develop. Given a set increment, such as a two-week sprint or calendar month, and the number of development units you have, it is possible to plan out a software project and estimate how much work can be completed. This estimation work is one of the many things that Microsoft Project excels at, however not everyone has Microsoft Project. Instead, you can use Microsoft Excel to do this type of work and achieve similar results.

Calculating Development Capacity:

To start with we have Development Units. This is a measurement of dedicated development hours which is what most project managers deal with in Microsoft Project, or you can substitute hours for Agile Story Points. For my example, I will utilize story points, but either hours or points will work.

Next we need to know the number of development resources that we will have available to us by Sprint or by Month. For this example, I am going to use 12 months (January through December).

The next value that we will need is how many units a single developer can complete in a given month.

Inputting these values into a table, will give us an estimated capacity for the project.

Story Planning:

What we need next is the set of stories and their corresponding unit values. For this, we start with 49 sample stories, each with a different unit value, in this case story points. Our stories will be completed sequentially in Excel, and their story points will be totaled as we progress. This summary is used to calculate what month the work will take place in. If we are over the sum capacity of the 12 months, then we would have exceeded our percentage capacity and note this as “Over Capacity”.

We either can remove stories or increase the number of developers for a given month.

Excel Template:

To do this in Excel, I created a Calendar worksheet with a table that listed out by month, the number of developers, the estimated velocity, and incremented story points. The calendar table does simple addition and subtraction. You can change the number of Developers and outside of the table, there is a value of Story Points per Developer that can also be changed.

Excel Software Calendar

In cell A4, we have 32 story points which we have already completed at the beginning of March. For the month of March we have an estimated capacity of 16 story points. Note, I have set the Story Points Per Developer value to 4 for this example. With the Calendar worksheet completed, we have a good overview of what our capacity for the next 12 months will be. We can now move on to story planning.

Next I added a Story Planner worksheet with another table that lists out the planned stories and estimated points. The Story Summary incrementally sums up the story points.

Excel Software Story Planner

For the Estimated Month, a VLOOKUP formula evaluates the story points to the values in the calendar table. The IFERROR is used to display Jan instead of #NA values.

=IFERROR(VLOOKUP(D2,calendar,4,TRUE),”Jan”)

The Capacity column calculates a percentage and if over 100%, displays a warning message, to let me know we are over our story points.

Excel Software Story Planner at Capacity

The formula uses the IF function to display the percentage if it is less than 1, or display Over Capacity message. You can also apply percentage formatting to the column to make it appear like in the example above.

=IF((D2/Calendar!$A$14)<1, (D2/Calendar!$A$14),"Over Capacity")

Summary:

Microsoft Excel is a very versatile tool and this tutorial illustrates some simple planning techniques that can be done using a couple of tables and some basic formulas. I have made a version of the Excel file, to use as a starter template:

Filed under: Project Management

JIRA Scrum Dashboard

JIRA Story IconOver the last year I have utilized Atlassian’s JIRA issue-tracking system for monitoring the progress of various scrum development teams. JIRA is a very versatile tool for Agile software development, however, like any other tool, the more you use it the more you find out about its limitations. In regards to scrum, I find the Active Sprint Board view to be rather cumbersome to use, if you are working with a large number of stories and sub-tasks. What we use instead for our larger teams, is a JIRA Dashboard. This allows us to view all the work in one screen and allows project managers to monitor the sprint progress as well.

Display Current Sprint Overview

To start with you will need to create three filters and share them with the project. The first filter is to retrieve all stories and task tickets for the current sprint. The next filter retrieves all sub-task tickets for the current sprint. The last filter is to retrieve any open bug tickets; this may be optional on how you handle defects in your project.

project = PROJ-X AND issuetype in (Story, Task) AND Sprint in openSprints() ORDER BY Rank ASC
project = PROJ-X AND issuetype = Sub-task AND Sprint in openSprints()
project = PROJ-X AND issuetype = Bug AND status != Closed

Now that we have our filters, we will create a new dashboard. I personally prefer the middle layout which gives you a smaller left column and larger right column; however you can choose whichever layout you prefer.

JIRA Dashboard Layouts

For the right column, add three Filter Results gadgets. Using this gadget, we can display Stories, then Sub-tasks, and then any open Bugs. In the Filter Results configuration, set the following columns to display for Stories:

  • Issue Type
  • Key
  • Sub-Tasks
  • Summary
  • Epic Link
  • Story Points
  • Status
  • ∑ Progress
  • Assignee
  • Linked Issues

For Sub-Tasks and Bugs, you do not have to add as many fields, but you can see what works for you based on the fields listed above.

On the left column of the dashboard, some recommendations would be to add the Sprint Health gadget and Sprint Burndown gadget. I also recommend adding the Issue Statistics gadget to display Status for Stories. Although I am not a fan of the Pie Chart Gadget, you can also add this on the left column to display Sub-tasks and the Assignees.

When complete, this overview dashboard will provide a quick and easy view of the scrum team’s current sprint work. It is great for reviewing before or after standup meetings, or for product owners who need to monitor specific stories.

Filed under: JIRA

Work

Office WorkerWe all do it, right? In fact when we are not doing it, we are most likely talking about doing it, more specifically how much more of it we have to do. But what exactly is Work? Is it a simple equation or is it more than that?

Work = Time + Effort

More recently, in our information age obsessed culture, we strive to not just complete work, but to be proficient at it. We as knowledge workers have to be proficient, we have to learn to execute more precisely, to eradicate waste, be energy efficient. This is how we come to think of work, not as something we produce, but as to how we perform it. It is not satisfactory to think of work as something we do, but something we need to excel at, to become better at, to improve. It is vital that as individuals we devote ourselves to thinking about how we do work, and less about how much of it we produce. Productivity should not matter to us personally, because productivity is no longer a goal for the individual worker.

What matters is the How and not the What. This is why we learn different types of business improvement models, like LEAN, Six-Sigma, Continuous Improvement, Efficiency, Quality Improvement, improve upon processes and products. If you are thinking, this does not make sense, because my business cares about productivity, and while this is true for the business, it should not be true for you personally.

For example, I once had a fellow project manager relate to me how they did not like how a particular computer programmer spent their time. The project manager was equating a programmer’s work as the amount of time they spent in front of a keyboard, writing code.

Work = Time

My response to the project manager was that we did not pay that person to write code, we paid them to solve technical problems with our system. I then pointed out that the programmer had years of accumulated knowledge and expertise, and just because they were not sitting in front of a computer, did not mean they were not thinking about how to solve our technical problems. It was more important to me, that the programmer provided their best solutions. If I really wanted a quick solution I knew that they could also provide this, but if schedule was not a problem, I always preferred to defer it until later. My advice to my fellow project manager was to manage the project, and not manage how other people do their work, because no one likes that and it does not produce better results.

In the case of project management, I see work as a series of never ending issues, which I run through my own personal system in order to attain resolution.

Work = [Problem = (Knowledge + Communication + Execution + Monitoring)]

Problem:

Issues come up every day, they arrive through email, in person, by phone, text, via your boss, customer, and sometimes by your own assessment of your project. In projects, everything fits into a Scope, Schedule, Cost category, but issues usually span some combination of the three. The other great truth is that in life all problems are people problems, because a process is just a series of steps. It is people who either do not understand the process or are refusing to execute the process, so in the end you have to deal with the people problems first.

Communicate:

This is the hardest part about life. You have to communicate! Ask questions, if someone comes to you with a problem, what is it that they are trying to solve? We are incredibly bad at figuring out what people want from us, if we do not ask questions. Communicate… define the problem, get agreement on what would satisfy all parties, and agree on how to monitor the outcomes.

Knowledge System:

Run the problem through your own personal knowledge system. Many people start out at a job and rely on the company to provide training and if that company has good documentation and processes, this is the system that people end up using. Long term this is not a substitute for a personal system. What I mean by that is that you should be a life-long learner and build your own system for being organized, focused, and having a proper toolbox of skills. There are tools that can help: task managers, Microsoft OneNote & Outlook, etc… try them out, take an online class, take a seminar, find what works for you. Next learn how to take feedback, get a mentor, someone who can give you honest criticism and who you can ask questions. Self improvement: focus on what areas you need for your work, my suggestions: improve your communication skills, learn how to give great presentations, get to know your customers, understand the entire cycle of your business, volunteer to help your peers. Coming back to my previous computer programmer example: accumulate knowledge and expertise. All of this becomes your personal knowledge system in time.

Execute:

Once you have run through all the possible ways to fix the problem and had the discussions with the necessary peers or teams, go and execute the fix, the changes, the solution.

Monitor and Learn:

Solving for X is not the end. You need to take the extra steps to see what the outcomes and perceptions are. You will find that getting feedback is often difficult, but it is important to learn about your mistakes and your successes. For example, one of my favorite tools is Microsoft Excel and though I depend on it, I have learned the hard way to always keep a backup of my original data, to triple check my final analysis, and if at all possible, to have someone else validate my results. The worse feeling in the world is knowing you made a mistake in Excel, five minutes after you have delivered your file. Always have a backup, always validate, always incorporate lessons learned.

Feedback can be as easy as three questions: How am I doing? What could I do better? What can I do different? If you are trying to improve your team, replace the “I” with “We” and keep asking the same questions after every problem resolution, or on a monthly basis. Most of all do not wait to the end of your project, as most people tend to forget what happened in the past.

Make Everyone Better

A famous basketball player once said that it is not enough to be a great player, you have to improve those around you in order to truly win the game. This applies in the work place more than ever.

Success is a measurement that can be shared.

Filed under: Project Management