Story points were invented to beat the ever true problem of underestimation. The design process of Concorde ended up costing 10 times more than they originally estimated. So, how to use story points in Jira to bring overly optimistic time estimations down to earth ?
- Story points suit relatively short, three-month projects. Story points rarely prove efficient in lengthy, multi-year projects.
- In most organizations a single story point is equal to one FTE, or Full Time Equivalent, or 1/2 FTE.
- The more complex a task is, the more room for error exists when estimating. This is why project managers use the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, 34, …) for estimations.
- The better a project has been looked into, the more often people will estimate tasks to days instead of story points. Forced to utilize story points many team members will use days anyway, and calculate them back to story points to satisfy management.
Story points in Jira
- Starting from Jira 7, story points are a standard feature of Jira Agile, and not Jira Core – the difference discussed here.
- It’s optional to use story points in Jira. You can always use days, or FTEs (Full Time Equivalents), or hours instead.
- GreenHopper plugin introduced story points to Jira long ago. The addon was later taken over by Atlassian and was on the market until Jira 6.
- Starting from Jira 7 you don’t need a separate app to use story points in Jira.
Interestingly, up to this day story points have not been integrated into Jira as thoroughly as one might expect. For example, most projects start with epics that a model Agilist would estimate in story points. Epics are to be divided into stories at a later stage of a project’s lifespan, but surprisingly no automatic decomposition of story points will occur.
How to make the best use of Jira story points?
Use a complete PPM management tool, such as BigPicture.
How to deal with story points? Several practical approaches
Let’s say, you need to estimate the duration of your new project.
- Pick the easiest to estimate task and express its value in story points. We suggest that you pick a relatively easy task and estimate it to a single story point, or 0,5 story point.
- From now on it’s going to be your “prototype kilogram from Paris”.
- One by one, estimate the remaining tasks by comparing their complexity to the prototype task. If the prototype task has been allowed one story point and a given task seems to be two times easier, then allow 0.5 story points for it. If the task being assessed seems 1.5 times more complex than the prototype, then grant it two story points. Or, if using the Fibonacci numbers (1, 2, 3, 5, 8, 13…), grant the adjacent number in the sequence.
- Ideally, estimate all the tasks within one meeting. Why? Browse through the Q&A section below for an explanation.
You could tell how much time a story point equals to in a given project after a few meetings with a client. Say, in your average project a story point is equal to one day. But you’ve realized you deal with a pesky, detail-oriented, demanding client. Therefore a story point in this project could equal to three days.
An average article for a blog usually takes four hours to author (1/2 story point). But in a given project a blogger deals with (a) complex topics, (b) foreign languages, (c) difficult to obtain graphics, (d) a lengthy acceptance procedure. So for the particular project the blogger might take one of the below approaches:
- estimate an article to 1 (or 2, or 3) story point instead of 0.5 sp, and we like this approach more,
- assume an average article will be, say, two times more complex. Than the article for this special client would still be estimated to 0.5 story point, but the blogger needs a story point conversion rate of two for the client, to effectively plan the work in time. If the blogger has five clients, the conversion rate of two would only be applicable to that single, demanding job.
We, a software house, generate demo screenshots of BigPicture/BigGantt/BigTemplate on a daily basis, let’s say 10 pictures per day. An average screenshot took 0.25 story point to author, so we would have needed a theoretical number of 2.5 graphic designers working 8 hours per day to keep up with delivering all the screenshots necessary. Read about velocity below.
Story points Q&A
Why are story points gaining popularity?
- Agile methodology has been popular for quite a long time. However, the Agile revolution is currently taking over traditional industries in Germany and in the U.S.A.
- Analytical minds in the IT industry like formulae, and the IT sector is where project management software, and therefore story points, are extensively used.
- Story points prove practical when both senior and junior staff members work on the same project. Consider a case of a bug that had been estimated to three story points. You have a senior that burns out 3 story points per day, and a junior that does 1,5 story points per day. Isn’t it easy to tell the project’s duration?
What does velocity stand for?
Velocity of a project, a.k.a. burnout, tells us how many story points drop from a backlog in a given time period.
- Velocity of 20 story points per sprint means that a team completes tasks worth 20 story points during a single sprint.
- A burnout of 60 story points per month means that a team completes the 60 story points worth of tasks during a single month.
Are there any drawbacks to story points?
The greatest shortcoming of story points is that you shouldn’t change your “model kilogram” during a course of a project. So if you need to evaluate some newly added tasks four months into the project, you should still base your estimation on the prototype task. But that original model task could have been completed long ago, or forgotten, or the perception of its complexity might have changed over time.
Who does use time units anyway?
Whether you’ve committed to story points or not, ordinary time units will occasionally enter the game anyway:
- A project manager will determine the number of necessary team members based on hours.
- Resources, such as a conference room, are accounted for in hours.
- Management boards tend to think “hours”.
- In regulated industries, with new laws effective on a certain date, you have deadlines, so you need to plan in ordinary time units, such as days.
Why do story points tend to be forced out of lengthy projects?
While short projects use story points extensively, multi-year ones occasionally end up with days as a basic unit. Why does it happen? In the IT industry a few months into a project a communication mess has cleared out, a client’s requirements have been recognized, a technology has been chosen; and people have learned the structure of the code. With the project having been known back to front by the team, tasks can be estimated more precisely. Hence, some project managers decide to use more intuitive units, such as days or hours instead of story points. But the other side of the coin is that many long-term projects continue using story points.
Why days and not hours or minutes?
In most organizations a story point is denominated in days, and not hours or minutes. Tasks are then seldom estimated to less than a quarter (0.25) of a story point. It’s just a salvo for inaccurate estimations.
Consider a task that was estimated to one story point. Chances are it will be completed in time – in a single day. Now think of eight very simple tasks that theoretically could be estimated to one hour each. Those eight tasks have almost no chance of being completed within a single day.
Understanding an issue, swapping between contexts or just relaxing, collectively consume astonishing amounts of time. Story points equal to days take care of human weaknesses, if people stick to the “0.25 story point” rule.
How to estimate a “big question mark” type of tasks?
Agile poker technique comes in handy. Each team member independently estimates a given task, ideally using Fibonacci sequence (1, 2, 3, 5, 8, 13, …). The closer the individual estimations are to each other, the better the chance for an accurate estimation.
Where do story points originate from?
Story points are generally credited to XP, or Extreme Programming, one of the most Agile project management methodologies.
Today pure Agilists favour story points over ordinary time units. Less orthodox teams, however, while still use story points, they tend to bind them to some set value, be it 4 hours, or 8 hours, or 0,5 day (FTE), or 1 day (FTE), or 2 FTEs, etc.
Firstly, is BigPicture suitable for change management? Managing change in both individuals/teams and systems engineering. Read more
Secondly, Project Manager vs Product Manager vs Product Owner. The Product-centric roles seem to be more lucrative and future-proof than the Project Manager profession. Let’s compare them.
Thirdly, How to select the right Scaling agile methodology for your organization? How do SAFe, DAD, LeSS, and Scrum of Scrums differ from each other? Do some of them fit certain industries or sizes of organizations better than others? How popular are they? Read more.