How Gliffy's Marketing Team Adopted Agile Methodology (Scrum) to Get More Done - and How You Can Too.
A few weeks ago, I joined ServiceRocket in a webinar to discuss how Gliffy marketing increases productivity and decreases wasted cycles by incorporating Scrum (Agile) into our project process. However, I didn't cover as much detail in the given hour as I would’ve liked to. I want to follow up with this blog post to discuss estimating projects through story pointing and the various issue types. If you have a shared system for estimations and use the same terminology you’re more likely to deliver not only complete projects, but expectations.
For the sake of reiteration, that this is how we Scrum at Gliffy - this isn’t a prescription for Scrum. You'll find other sources you can compare / contrast and to ultimately create a version of your own. It is after all, being agile!
In the diagram above, you have meetings that feed into the next (left to right): Backlog Grooming, Sprint Planning, Daily Standups, and the Sprint Review. The issues chosen and discussed in these meetings make up the very core of your sprint. From Backlog Grooming to your Sprint Review, these issues are what will be discussed. So what exactly are issue types, story points, and why are they assigned Fibonachi numbers? The explanation is a story point in itself (Scrum joke! I promise you'll get it later). :)
Let's start with story pointing. Story points are estimates to a issue that represent complexity of the issue, NOT the time it takes to complete the issue. For team uniformity, story points are usually voted on as a team. This works when your team has similar skill sets, such as your engineering team(s). However, business teams don't typically share similar skill sets. In my case, I have content marketers, a digital marketer, a customer support team, and front-end engineers. Our process is a bit different - whoever is the ticket assignee describes the ticket, what and who are involved, takes a guesstimate on the number of story points it will take for him/her to complete, then will have the team agree to whether or not the guesstimate was calculated properly. If so, a number goes into the Estimate box. If not, those who disagreed with the guesstimate will explain their reasons.
Cool, you've gotten this far. What numbers can actually go into the Estimate box? Fibonachi numbers. I won't get into the theory behind the sequence of numbers - all you have to know is that the last number is equal to the sum of the last two numbers, starting with 0, 0.5, 1, 2, 3, 5, 8, and so on.
How we assign story points to issues:
- 0 - Trivial text change
- 0.5 - Well defined problem, small change, no unknowns
- 1 - Small problem with a finite amount of time, little to no unknowns
- 2 - Well defined problem that takes more time, there may be a few unknowns
- 3 - Moderate problem with a little risk, a few unknowns
- 5 - Moderate to difficult problem that will take more time and has more risk, several unknowns
- 8 - Large problem, one that can't reasonably detailed out completely during sprint planning and comes with risks
Everything after 8 should be broken up into a few or several issues. If it’s your first time story pointing, use 1 as the starting point - each member of your team should be able to complete roughly 1 story point per day. That said, story points are based on “feel." As teams continue practicing story-pointing together, accuracy and complexity will normalize and improve over time. My favorite fallacy with story pointing is that all story points can simply be added together to achieve the expected result. Wrong! An 8-point problem does not equate to eight 1-point issues. Remember that 1-pointers have little to no unknowns, 8-pointers cannot be detailed out in a single planning session and is risky.
Between the webinar and this post, I’ve only really discussed Stories. That was intentional because they are arguably the key component to any Scrum.
You’re probably wondering - aren't there other issue types that go into Scrum? Absolutely.
Within the Gliffy Marketing team, we keep it fairly simple with only 4 issue types - Epics, Stories, Tasks, and Sub-tasks. Engineering teams typically have more types including Bugs, Improvements, New Features, Specs, etc. You can add those issue types, but we didn’t think it was necessary for our purposes. I’ll explain each issue type we use, from largest to smallest in size, where size is represented by story points.
Epics are the biggest issue types, they usually contain several Stories, Tasks, and/or Sub-tasks. It is therefore the parent issue amongst other issues. The rule of thumb is that you cannot complete an Epic in one sprint, there are too many unknowns needing to be scoped and typically has crossfunctional activities. A few examples of Epics can be: website creation, event sponsorship, or retargeting campaign for the website. Epics don’t usually have story points assigned to them as complexity is rolled up from the Stories and Tasks.
Stories and Tasks are sibling issue types that should make up most your Scrum. Stories are usually written in the form of a perspective and has acceptance criteria. For instance, “a user would like to be able to purchase your software service via PayPal so that they can complete their task using your software.” The acceptance criteria is that PayPal is an accepted form of payment on all transaction and commerce pages on the website. On the other hand, Tasks are simply that… Tasks. I’ve seen teams interchange Stories and Tasks, but we treat them as must-dos in order to complete the Epic or Story. An example task for the previous example is to get the API calls or web hooks from PayPal to link to our database.
Sub-tasks are the last and smallest of issue types we use, they are always linked to their parent issue and are typically 0 pointers. We like to use Sub-tasks mainly for Stories, it helps us breakdown the tasks needed for completion. For instance, if we were to create a new demo video to feature our Atlassian plugin, I would have a Sub-task to subscribe to a video hosting service and recording a voice over with our talent.
I’m hoping that between the webinar and this post, you have enough in your arsenal to get a version of Scrum going with your business team. It has really improved our communication throughout the company, the timing / delivery of projects, and the expectations we set for one another. People are happier, sprints are almost never disrupted, and company culture is maintained at a very high threshold.
If you have any questions or would like more detail on any of the ideas discussed, either comment on the page or shoot me an email directly at email@example.com.
Cheers to Scrumming!