Publishing code live weekly or every other week as it’s ready.
Using JIRA to store bugs, plans, and good ideas.
Problems we’ve faced:
Starting any project that takes more than a day or two for a single developer, as priorities can change week to week.
Any estimate on a project more than a few hours is always off by days.
What I want:
To have a few fixed things to work on each week so I can complete them, publish them, and then feel good about it.
To get better at estimation so we can start planning ahead more than a few days.
Keep stakeholders in the loop with developers.
A process that lightly sits over current methods of issue tracking.
Smoothly handle the inevitable emergencies that come through for the website.
What we tried first, starting in February 2013:
Took all our old jira tickets and put them in an “In Queue” bucket, aka “backlog.”
in JIRA terms, bucket started out as a “Fix Version” but eventually became a “component.”
We’d review the backlog, pull some things out, add rough estimates to them, and attempt to put together about 2-3 weeks worth of work.
We’d create a bucket for that group, (started out as the JIRA field “Fix Version” and eventually became the JIRA field “Sprint”)
We named it like this: *Primary Goal* due on *Month* *Date*
Examples: “Fix Browse Support due Feb 28” and “UVC Updates due Feb 19”
Some things grouped up organically (like a bunch of SEO fixes) and so we put those into their own buckets (Fix Version, later Epic) but didn’t put a due date on them.
We went through all our old groups that didn’t fit this convention and emptied them into the backlog or closed them.
When emergencies came up, we intended to create a ticket, set it to blocker, and move it into the currently active sprint and move something lower priority out.
We repeatedly missed our due dates because of my poor estimation capabilities and because no one bothered to move items out when emergencies were added in.
The idea was we’d launch whatever we had on the due date, and move the remaining items into the backlog and re-assess priorities for the next sprint.
Not a bad idea, but we were consistently getting to less than half of the planned items. This lead to feelings of failure and disappointment.
Each sprint will have its own branch. Current sprint branch will be merged into staging when it’s complete.
This is at odds with publishing mid-sprint, and since the items in sprints aren’t related this means one change could be waiting on a completely unrelated request.
It’s also at odds with the successful idea of “feature branches” and the other successful idea of “commit often.”
What we’re starting to do different now, in August 2013.
Shortened the intended length of the “sprint” to about a week because it’s easier to estimate that and semi-emergencies can just be put off until the next sprint.
Stop setting due dates before work even started.
Name them after the sprint start date and the most important feature or goal of the sprint.
Like this: “2013-08-20 Web RTC Sprint”
The idea is you work on the sprint until it’s done. If something is taking a lot longer than planned, break it up and put what remains in the backlog.
Hopefully this will lead to feelings of happiness as sprints are completed, improve our estimating skills, and have something to publish every week or so.
Actually take something out if we move an emergency into the sprint. Designate this as a specific person’s job.
Use feature branches and feature toggles. Don’t base the branches on the sprint.
Some practices that have been working well for months:
Set the primary stakeholder as the reporter or watcher for as many of the tickets as is practical. This way when one of our stakeholders forces an emergency into the current sprint, the other stakeholder sees us bump something to make room for it. This transparency means bumping something is easy with a good reason or a real emergency.
As tickets are completed, commit them to staging so the stakeholder can see the change on staging and approve or suggest changes.
Tester, Stakeholder, or other developer will close tickets after confirming them, or re-open if there is a problem. The assignee will not close their own ticket unless it’s trivial or they are the primary stakeholder.
Prod updates should always happen at the end of sprints and encouraged mid-sprint.
Improvements to the publishing process I made since February:
Production server should be made not to pull bin files from staging anymore. They should be built on production or a build server.
Setup a test server (besides staging) that can build its own bin files from a repo holding code not necessarily ready for production.
Staging stays on the master branch at all times and is the last stop before code goes live.
Before all this we had to both test on staging, but also clear out any non-prod-ready code before a launch so IT could copy the bin files from staging. Oh and I was building all the DLL files on my development machine and copying them via Remote Desktop to staging.
