Story Points

At the core of Agile development is the sprint. It is key that we communicate to the stakeholders what to expect in a sprint, and to do this we have to have a realistic way to determine the size of a story.

Ideally assigning points to a story is as simple as reviewing the amount of work, determining the time expected to develop and test, and to use a scale of small = 1 point, medium is 2 points, and large is 3 points. 

You are done! 

Yet is not this simple because points are not just used to judge the amount of work on a single ticket. Ideally we will review all the points on the tickets to determine the amount of work completed in a sprint.  Over the span of multiple sprints, you can review the amount of work the team completes and then predict future work by averaging points completed per sprint.

This is velocity and it is used to adjust the roadmap for the project.  Knowing your team's velocity is key for allowing the team to successfully predict what can be accomplished for the project's first "go live" and all subsequent releases.

With the goal of using points to represent the velocity for roadmap planning, you can now plan the tickets for a sprint. The small, medium, and large ticket sizes roughly equate to the number of days it will take the various team members to complete the work.  A small ticket will be about a day, a medium will take a couple days, and a large will take a week.  Anything larger is too large of a ticket. 

Early in a project this may seem like guesswork, but as a team matures this will be a very accurate tool for managing what is deliverable in a project.

Bugs, Stories, and Tasks

Our team's general practice is to assign each development ticket as a bug, a story or a task. The tool of choice for ticket tracking is Jira and we use the "ticket type" feature. The points allow an “at a glance” view of any Jira ticket or Jira board.

Here’s a quick outline of each ticket type.

• Bugs - Our team uses this ticket type to mean a small change to the software that takes a couple hours to complete.  It may be a small defect or a very small enhancement.
• Stories – These are the most common type of Jira ticket and include participation from the planning team, the development team and the QA team.
• Tasks – Similar to stories, but tasks are used when a developer does work that does not need to be tested (i.e. Set up server) or a tester does work that was developed in a separate ticket (i.e. regression testing).  

Judging the amount of work

The most common criteria for determining the story points is to review the complexity, effort and doubt. 

• Complexity is the involvement of multiple parts and the interaction of these parts to accomplish a task.
• Effort judges how much activity the developer or QA teams need to perform to complete the ticket.
• Doubt is used to reflect the unknown part of a ticket.  Although the requirements may be clear, the solution may not be.

The complexity, effort and doubt can be measured and combined to help determine the story points.  

Here’s a real life example.

On a recent project, I had to make a simple list of transactions. I judged this as a low complexity because I had an understanding data model and there were no changes. However, the amount of work is large because the users prefer a new page for this functionality.  Fortunately, there was no "unknown" feature thanks to a team member outlining what the users wanted on the new page.

This would be complexity=S, doubt=S, and effort = M, which I believe would be perhaps be 3 days of work.

Let’s ask the people doing the work!

The developers on the team may have differing views about the solution and that the Customer Liaison may want to consider.  The QA team may have input that affects the option of the Customer Liaison and the Development team.  The interactions between each member of the group can directly influence the task at hand, and the points. 

Typically, this is a beneficial conversation to have while planning a sprint.  The goal is to add clarity to the story writing and points.

                                                                             

Working with a team

Each team has its unique makeup and unique expectations.  The team will have developers and QA teammates with varying expertise and experience, but you can expect every team to have leaders. 

A lead developer can accomplish tasks in a third of the time of the rest of the team, but assigning points based on this single developer’s skill level can quickly provide an impression of a wide swing in velocity each sprint.  Most often this will happen when an expert developer finishes tickets in the current sprint early and can then very quickly complete other tickets.  The following sprint the expert developer may not finish their work early and the team does not benefit from the rush of extra work. 

Assigning points with more complexity to the lead developer and valuing the points lower will give a clear presentation of the velocity.  Then the expert developer can still contribute any extra time to other tickets without causing such a wide swing in the velocity. 

Of course, this is a catch-22. On a self-organizing team, no one assigns work to a developer. Furthermore, a team has no velocity at the beginning of a project because velocity is a proven quantity determined by reviewing the past, not anticipating the future.