In any project determining the level of effort (LOE) can be a daunting task. Worse yet the debate over which scale to use and how to apply weight to each point can be a rage-fest of unproductivity in and of itself.
Consider this scale like pasta, throw it at the wall and see is it sticks…
We are estimating is using T-Shirt sizing and is generally based on the level of effort for the developers that are part of the team as well as a certain amount of self QA. This does not really include the amount of time QA or PO personnel need to put into a ticket or ensure that the work has been completed appropriately. So be cognizant of the time needed for QA and UAT as that often lays outside of the story pointed LOE.
The following is a simplified guideline aimed at helping introduce story pointing into an organization. The goal of the matrix is to give everyone involved a level playing field to start from kick starting the adoption of some sort of agile or scrum process.
| Point Level | Level of Effort | Description | Example Tickets |
|---|---|---|---|
| 0 | None (or due to recent defect and not going to give additional points to fix it) | Actions conducted by non developers, or simple verification tasks | |
| 1 | Less than an hour | Activating a plugin and verifying it's operation | |
| 3 | 1-3 hours | Updating a plugin or theme via composer | |
| 5 | Less than a day | Modify placement of a widget and verify data renders properly on the website | |
| 8 | 1-2 days | Add new fields to web service along with adding fields in database structure and then verify data shows up properly in RabbitMQ | |
| 13 | 2-4 days | WordPress upgrade | |
| 21 | Too big, needs to be broken down into smaller stories | Create a new marketing website |
Herein lay the rub story points are not a hard fast replacement for time. So while the matrix does a simple approximation of points to time it is not the hard fast rule and more of the guideline for getting your program off the ground. It is unfortunately the easiest way to start crawling with story pointing. As your team grows and complete a few cycles you should replace the time metrics with tickets that the team can reference in future planning sessions. these tickets become known as barometer tickets.
Is this project’s LOE larger or smaller than barometer ticket X?
A final note about vague work requests. Nothing is more infuriating to a developer then being asked to go build all the things but I have no idea what those things are yet so please trust me and put this effort into your sprint that starts tomorrow so you can stat working on it right away. This is a sign you may have an evil PO on your team.
So in order to combat this we have an emergency sprint queue that sits outside the active sprint. Once the evil PO has figured out all of the details then we story point the fluff ticket and hold them accountable to removing an equal amount of effort from the active sprint in order slip in this Do It Now project. Obviously it goes with out saying that emergency work requests that pop up mid-sprint are handled in a similar fashion. Just remember to consider the remaining work days in a sprint when shuffling work.
Shuffling ticketing in and out of an active sprint is extremely disruptive and counter productive.
I hope that this helps you kick start your process.