In theory, this is where all the work begins. This is when, instead of a computer, we use sticky notes to plan a project. Sizing is a compass for the correct assessment of the effort of tasks and avoiding the inflation of effort of tasks.

The tab consists of two tables:

• main steps,
• steps.

Each of the tables consists of several columns bearing the names of T-shirt sizes. In the first step, all the sub-goals and goals (when there are no sub-goals) must be assigned to one of the sizes between XS and XXL in the “main steps” table.

This task is to make a preliminary division of the project goals according to their effort – not the realisation’s length. During the division, it is not important how much objective A’s achievement differs in terms of effort from objective B. All that matters here is to determine that objective A’s achievement is more, less or equally effort-intensive as the achievement of objective B. Doing this task can start by selecting a sub-goal that is moderately large and assigning it to size M or L. Another way is to select a sub-goal that is the least effort and assign it to size XS. We evaluate the remaining sub-goals by comparing them with the first sub-goal assigned to the table’s correct size.

The next step is to copy the work packages for the individual sub-goals from the “roadmap” tab and paste them under the same sub-goals in the “sizing” tab in the “main goals” table. After doing this, you may find, for example, that sub-goal C is not size “L” but “XL”. If this is the case, move the sub-goal and its work packages to the column with the correct size. If you run out of rows in the “main steps” table, put them somewhere between row no. 7 and 22.

To easier distinguish sub-goals and goals from task packages, sub-goals and goals are marked in blue. Job packages are marked in green. When a work package is found in only one of the tables, it is coloured white (e.g. cells E10 and D50).

Now proceed analogously with the work packages. We choose the smallest package and copy it into the table “steps” into the column marked “XS”. Alternatively, you can select a package with a medium effort and copy it into the column labelled “L” or “M”. Then we copy the other task packages into the corresponding columns of the “steps” table – evaluating their effort concerning the first package assigned to the “steps” table.

We can now convert the t-shirt sizes into story points as follows:

• XS=1
• S=2
• M=3
• L=5
• XL=8
• XXL=13 or 21

Why these numbers? These numbers form the Finnocacci sequence.

This is a common and naturally occurring progression that describes how things grow. The growth of rabbit populations, seashells, and tree branches all follows the Fibonacci sequence- as do problem sizes and the efforts required to solve them. […] It makes the estimating process much faster and more efficient [fn]M. Griffiths, 2015, PMI-ACP Exam Prep, RCM Publications, p.278[/fn].

Several things are essential in scoring:

• The points reflect the effort, not the length of the work package
• The effort needed to complete the work package should take into account: work volume, risk, uncertainty, complexity
• The scoring is done by a team

You can find additional materials about story points/velocity points at the following link:
https://www.mountaingoatsoftware.com/blog/the-main-benefit-of-story-points
https://www.mountaingoatsoftware.com/blog/story-points-are-still-about-effort

Before proceeding, review all the work packages in each column of the steps table and ensure that the tasks in one column do not differ significantly in terms of effort. If a work package requires considerably less or more effort to complete, move it to the appropriate column.

Now we can return to the roadmap tab, and before each work package, enter the appropriate number from the Fibonacci sequence in square brackets.

The data for the tab is entered only once, at the beginning of the project. Work packages added to the project during its duration can also be added to the “main steps” and “steps” tables, but this is not necessary.

What is all this for? The primary purpose is to group and evaluate the effort of the work packages. People are poor at accurately judging the difference between two things: how much Jay is taller than Marry. Instead, it is easier to say that Jay is taller or not.

It is better to be roughly right than precisely wrong. [John Maynard Keynes].

Another reason why the sizing of task packages is essential is the phenomenon of “inflation” of task effort. Imagine that you are working on task X, which should be completed in a week. It took you two weeks. It will be convenient to explain the delay because the initial assessment of effort was inaccurate, and the package should have been rated eight instead of three. To avoid the effort distortion, it is enough to compare this task with other tasks classified under sizes three and eight to quickly detect an attempt to make a poor excuse for delaying the work’s completion on time.

Why is the assessment in points and not in days or weeks? If we are assessing effort in a group, work package A may be completed in a week for Jay and in a day for Marry because she is, for example, more experienced. When the assessment is made in points, it is easier to agree that work package A will take three points and work package B as much as five points, although the actual duration will be different for both people (but we will discuss this later).

Do you find it laborious to fill in the “sizing” and “roadmap” tabs with data? Compare the workload of this method to planning a project by the waterfall method using, for example, MS Project. If you have ever planned an entire project in MS Project, then you know that the effort required to fill in an MS Project file is much greater than filling in a few cells in Excel. A shorter way to plan a project that I know is to plan in your head. I don’t recommend this to anyone, though 😉

Let’s go back for a moment to the theory of the sizing tab mentioned at the beginning of the description. Pre-planning a project in an agile way is greatly facilitated by a large whiteboard/wall, sticky notes of two colours and markers. Using these instruments, you can quickly build something similar to this:

The post-its can be re-pasted between columns, combined with each other and organised in new ways. It is also essential that the whole team can be involved in the planning process and not just the project manager. When the board/wall is not available to the team at all times, you can take a picture of the final version and then transcribe it directly into the roadmap. This saves a lot of time while achieving better results at the same time.

Backlog Tab

This is the heart of all agile project progress management. Here we record the progress of the work. Here we assign task package owners. Here, finally, we specify what is to be done and when.

To get started, delete all data from cell B7 to BB200. However, DO NOT DELETE THE DATA IN COLUMN “J”. In the next version of the file, you will be able to do this. Not now.

In cell M6, enter the date you started the project.

At the top of the table, on the second row, you have two buttons, “Roadmap to Backlog” and “Backlog to Roadmap”.
Press the “Roadmap to Backlog” button. This will download the data from the “Roadmap” tab. In this way, we have created a list of all currently identified work packages.

In cell D2 the default iteration length in weeks is entered. I suggest leaving it for four weeks. When your project is less than three months, you can reduce this value. When the project is longer than two years, you can consider increasing the iteration length.

Then convene the project team and choose which work packages will be completed in the first four weeks (iteration length). To make the task easier, filter the work packages in column “I” so that those that belong to phase one remain. Now, in column “K”, enter the number 1 for those packages that the team believes will be completed in the first iteration. Sum up how many points will be scored in iteration no. 1 (column D) and enter this number in cell D3. This is your estimated rate of work.

Now in the last filled cell of row no. 5, you can see how many iterations it will take you to complete the first phase of the project, and in the row below, you can see the expected completion date. Then assign the remaining work packages from the first project phase to the subsequent iterations.

In the next step, we will focus on the first iteration. Assign each work package in iteration no. 1 to a responsible person from your team. Then break down each work package into more detailed tasks, writing them in column “G”. Verify that the work package’s effort intensity has been correctly estimated. If not, you can compare it with work packages that have the correct effort intensity, and if indeed this work package should have a different score, enter it in column “H”.

During the daily/weekly team meetings, update the status of the completion of each work package in column “N”. When the status is set to “Done”, points will be assigned for completing that work package. When work has not been completed in an iteration, change the iteration number in column “K” for that work package to the next iteration.

Some cells in column “K” can be pink. This means that these task packages have not yet been allocated to any iteration. In column “C”, some task bundles may be red. This means that these bundles have no points given. To assign points to these tasks, select the task without assigned points and press the “Assign points” button.

When you want to add a new package of tasks to the list, you can do this in two ways:

• By adding them at the end of the list in the backlog tab
• By adding them at the appropriate place in the roadmap tab

After adding the package to the list, press the “Backlog to Roadmap” button if you choose the first method. This will bring up two windows in succession. In the first window, you have to select the goal and the sub-goal that this package is supposed to support. In the second window, select the project phase to which the task package belongs. This will add the package to the “Roadmap” tab.

If you choose the second way, after adding the work package in the “Roadmap” tab, return to the “Backlog” tab and press the “Roadmap to Backlog” button. This will update the new list of work packages.

I prefer the second way because then I have the project goals in front of me, and I can quickly tell if the work will add value to any of the project goals.

What if a task takes a while to complete for a team member, but you have to wait a long time for its completion due to the specifics of the task, e.g. ordering an injection mould (submitting a request will probably score 1 point but it will take 3 months to complete it), testing an engine (preparing and launching a test will take 3 points but the test will take half a year)? This may distort the estimation of the completion of a phase or the whole project. The solution is to add up the expected waiting times due to the task’s specifics and then add them to the timed completion date of the phase or project.

From the point of view of value creation, it is not important to which package or which iteration lag time (time that has to be passed before the next work package can be started) should be added. The value will be delivered with a release what is, in our case, phase no. (assuming that it reflects the achievement of one key milestone).

Refrain from detailed planning of the entire project. Practice and theory are ruthless in this respect; it is impossible to predict all the design work at the start of a project. Trying to plan them is, therefore, a waste of time and resources.

So how do you predict the completion date of a project?
When you have a fixed completion date: plan (preferably backwards) the completion of the main work of a priority objective. When there are enough time and resources left, add the next main work packages of the next priority objectives. Leave a time buffer of 30% when the planned work scope is clear and agreed with the client. On the contrary, should the buffer in the initial planning phase be larger?

This buffer will be gradually reduced as the project progresses, and additional work packages can be delivered. Honest and open communication supported by expert knowledge of the anticipated progress is essential. Hurrah optimism and unconditional promises to fulfil all wishes by the deadline is not the domain of professionalism.

Consider whether you would prefer to be 95% sure that the MVP (minimum viable product) will be delivered within the time you set and 40% to achieve the other goals? Would you rather be assured (cheated) that the project will be completed on time and then receive its products three months later?

For many sponsors and clients, a time buffer of more than 5% in project planning is inconceivable. As a result, 60% to 90% of projects end up late.
https://www.researchgate.net/figure/Percentage-of-projects-with-time-overrun_fig2_258764637

When you don’t have a fixed deadline for completing a project, plan only to complete the first phase and estimate the completion of subsequent phases proportionally based on the expected amount of work and the deadline for completing the first phase.

Below is a chart that illustrates the approximate accuracy of planning depending on the progress of the project:

In this part of the spreadsheet, we register all project risks (understood as threats). The following parameters describe each risk:

• Date: enter the date the risk was added to the table. The date of addition to the table should be as close as possible to the risk identification date.
• Risk name: briefly describe the risk
• Phase: in which phase of the project the risk is expected
• Impact: is a numerical rating from 1 to 5. A number 1 means that the risk when it occurs will have a marginal impact on the business value achieved in the project. Number 5 means that the project will not deliver or deliver marginal business value when the risk occurs.
• Prob. (probability) – a value between 0 and 100%. A probability value of 0 means that the risk will not occur. When adding to the list, Risks must have a probability value greater than zero and less than 100%. 0 means that there is no risk. 100% means that the risk will occur. Thus it is not a risk but a fact. The probability value of risk may change during the project.
• Sev. (severity): it is the product of impact and probability. This field is filled in automatically
• Decision: this is a suggested decision to be taken by the team based on the severity assessment. This field is filled in automatically.
• Strategy: there are five possible responses to the risk:
  ○ Avoid– is when the project team acts to eliminate the threat or protect the project from its impact
  ○ Transfer– involves shifting ownership of a threat to a third party to manage the risk and to bear the impact if the threat occurs.
  ○ Mitigate– action is taken to reduce the probability of occurrence and/or the impact of a threat.
  ○ Accept– risk acceptance acknowledges the existence of a threat, but no proactive action is taken.
  ○ Escalate– escalation is appropriate when the project team or the project sponsor agrees that a threat is outside the scope of the project or that the proposed response would exceed the project manager’s authority [fn] PMI, 2017, A guide to the project management body of knowledge. PMBOK, Project Management Institute, Newtown Square, Pennsylvania, p. 443[/fn]
  For more, see PMI, PMBOK GUIDE, p. 443
• Action: Here, we can specify the actions performed to implement the strategy (column “K”).

Once a month, we assess the probability of the identified risks and enter them in the appropriate column (M, O, Q, …). During the monthly review of risks, we can also add new risks.

The last cell we should look at is cell “C4” – actual phase. By entering in cell C4 the project phase number, we can see the risk graph of this phase in the “Dashboard” tab. Number 0 means subgroup of risks of all phases. What is it for? As I mentioned above, the total risk severity index should decrease during the project. Sometimes, when we do not have a clear knowledge of what will be implemented in subsequent phases, we cannot immediately identify all the project risks.

Consequently, further risks will be added as the scope of work of subsequent project phases becomes clearer. This, in turn, will lead to a continuous increase in the total risk severity index – which is a sign of too superficial risk analysis. This situation should not occur, however, when we analyse the current phase of the project. The total risk severity index should decrease with the progress of project works.

Graphical representation of data from the “Risk” tab can be found in the dashboard tab.

Summary

The described tool is not the only and always right way to manage projects. If you manage highly repetitive and similar projects, it is probably better to use MS Project. Perhaps your company dictates which tool you should use. In other cases, the tool presented above works great.

Sometimes, however, it is so that one thought or idea quickly turns into an outline of a project, the need for which must first be verified without unnecessary formalities, then the tool described above works great. It allows you to specify the work in detail in the next few days/weeks so that it supports the implementation of the task set for the team without losing the view of the broader perspective on the project.

I have used and still use this tool to manage projects of different sizes and types, from those where you know that nothing is known to those where the only unknown is what time on Friday in two years the production start should take place (SOP).

If you would like to try out my project management tool, please let me know your experience if you encountered any problems and if you have any comments regarding current or missing functionalities.