Surging Forward With Scrum
Welcome to Our Mess
I joined a startup one summer that was doing well, but in a somewhat messy fashion. They had a flagship product bringing in about $2 million annually, a loss-leader product comfortably coasting and a new product in “secret beta”. My job was to flesh out the product, in particular the UX, of the secret beta.
When I arrived, the workflow process was something like this:
- Pick some pressing issues, guesstimate how long it would take to do them.
- Work on them until their complete. Either cut back if they’re taking too long, or buy extra time if needed.
- Take note of technical debt.
- Schedule in time to clean out some technical debt.
Features were being built, the app was getting better, but something was off. I was surrounded by very talented and creative developers, yet development was about a year behind schedule and there was no real launch date in site. I’ll admit, at the time I figured this was just the nature of the beast and didn’t bother thinking of a solution.
Scrum it. Scrum it Good.
One of the lead developers had enough. He had been part of the entire length of the “year behind schedule” and so he conducted some research on best team development processes. What he found was a process called Scrum.
Scrum is actually a rugby term, loosely meaning “an ordered formation of players, used to restart play, in which the forwards of a team form up with arms interlocked and heads down, and push forward“, in other words, a team working closely together to get a very important task done. The term has since been taken over by the software development world, in the sense that it’s now defined as a form of project management an no longer tied back to rugby in that context.
There are different ways to scrum, I’m going to share the method I’ve been using, as well as my thoughts on it.
Choose a Sprint Period
Scrum revolves around short time periods called “Sprints”. The idea is to have a strongly defined list of tasks that you are committed to completing in a strongly defined period time. I’ve been using a two week sprint. This includes the estimation period, which is a solid day or two of planning (remember, the task list is “strongly defined), as well as burn-down day where you can bask in the glory of your work and reflect on how it could be improved the next time around.
Estimate Your Tasks
This is a tricky one, so bare with me. When you estimate scrum tasks for an individual sprint, you’re estimating it based on points. Points in turn are based on an estimated difficulty level. The points are scaled based off an overall amount of point allotted for each sprint. Still with me? Here is an example:
- A sprint is 14 days
- A sprint has 100 points
- Each individual task can have anywhere from 0 to 100 points. If you give a task a 100 point estimate, you’ve maxed out your sprint, which means the sprint will only have that one task in it.
- Points are based on task difficulty, not the amount of time it will take.
Estimating by points as opposed to by time makes sense because you never really know how long something will take. It’s the nature of the beast – things take longer. But you can estimate by points, understand what you’re up against and stick to the plan.
Break it Down
The tasks I’ve been talking about are often called “User Stories” or “Stories” for short. A Story is defined answering the questions of “Why are we doing this?” on an overall and detailed level. Each Story has Acceptance Criteria attached to it; a definition of what the product should look like when that particular Story is complete. Lastly, each Story is broken into however many sub-tasks it needs.
Enter Scrum Master
A birds-eye-view is important when the development team is knee deep in code. This is the Scrum Master whose role is to help develop the Stories, their Acceptance Criteria, their Sub-Tasks, and very importantly their acceptance. When a developer finished a task, it has to be reviewed and accepted. If it wasn’t done correctly, or if the scope of the task needed to be changed, the work is rejected and the developer gets back to business. A task is complete once it is reviewed and accepted.
To sum it up, scrum is all about setting short, realistic goals. It’s about defining your goals and having someone there to hold to accountable for them.
My Problem with Scrum
Scrum can get dumb because it neglects the human element. It neglects the idea that Acceptance Criteria is written by a certain person with a certain writing style. A task by definition can be rejected because it didn’t fill the written Acceptance Criteria as it was written. Another issue I have with Scrum is that you sometimes lose the forest by paying too much attention to the tree. You can become obsessed with completing sub-tasks and stories while losing an overall view of the app. Good planning sessions take the overall app in to account, but the nature of the web is that things are dynamic. Presumably a 14 day sprint is short enough that the tasks set are still relevant from the start to finish of a sprint. But you never can tell. The same idea applies to bug fixes, which are not accounted for in planning but may show up in the middle of a sprint and could be crucial to fix in the case of a live app.
These are all issues that can be solved and should be solved with proper team communication, retrospectives and planning.
All in all, I’m a fan of Scrum. The difference in quality and quantity of work from pre-scrum to scrum is phenomenal. I would recommend scrum, as well as the cool tools that help organize it, to any development team. And truth be told, you can use Scrum methods to organize almost any project.
Read more about Scrum, as what I’ve shared with you is my point of view and probably just the tip of the iceberg.