I'm a new user of Atlassian products and searched through the knowedge base and didn't find quite the right info, which is why I'm posting here.
We are trying to use Atlassian tools (Jira, Confluence primarily) as project management tools for research tasks. Some of these require software development, while others are more general in nature. We are just starting to implement story points to estimate task complexity.
Sometimes we are required to attend a conference. While this is not complex, it does take quite a bit of time. So, if I rate it low in story points (because it's easy, low risk, and well known) it has the potential to lower my team's velocity. If I rate it high just because it takes a lot of time (a full week out of a 2 week sprint), that seems to defeat the purpose.
Does anyone have best practices for estimating story points in a situation like this, where we are trying to capture everything from high level PM functions (attend a conference, develop briefing charts, etc.) to the details of the technology development?
I use degree's of difficulty for story points. You want to set this consistant story point value concept across the company so that everyone is on the same points scale.
Here's my points scale with some cheezy examples of stories to go along with them.
1's are easy - do a simple task like build a vm. I dump conferences in this because, lets face it - while they're attending conferences they're also still busy doing a few other stories with their own values as well. Conferences also affect velocity - so why not give it a 1?
3's are more complex - stand up a ha cluster and validate failover
5's get into higher degree's of difficulty - Migrate an entire Jira environment from Windows / MS SQL to CentOS / PostgreSQL. (ok maybe that should get a 7)
7's get my max difficulty and usually have the longest sprint overlaps. It's the let's architect a new AWS Tenant and migrate the on prem DC to it kind of work.
If someone gets a 5 or 7 point story, they're clearly not getting assigned very much else. You'll have to play with the valuation of stories initially. Perhaps have a round table discussion and then look at the results for your org.
When you start getting consistent burn down charts and good team feedback about workload in the Sprint retrospective meeting, then you know you've got it right.