I run a small software team of 4 developers (including myself.) We report to a different team who sets the priorities for development of a custom software platform that runs the company operations.
This is what we're doing right now as our "agile" process. It's simple and straightforward, doesn't require many meetings, and it's working pretty well. Your mileage may (will?) vary though, so adjust as needed.
Planning / estimation
I meet regularly with the stakeholders, a group of 4 employees from various parts of the organization. We discuss ideas for new features, work together to flesh out the problems we're trying to solve, and sort them by priority.
I use a rough estimation scale to provide an idea of the level of complexity involved in a specific request:
- 1 point: An easy/obvious change that I expect to only take 1-2 hours to change and deploy.
- 6 points: A more complex request that might take 1-2 days to finish.
- 30 points: An involved feature that I expect a developer to spend 1-2 weeks on.
If it doesn't fit clearly into one category, it automatically gets bumped up to the next category. If it's more than a 30-point item, we break it up into several cards.
I made up this scale because it's something that works with my brain. Trying to do a linear or fibonacci point scale is something I could never wrap my head around. I can estimate whether something is a 1-hour task or a 1-day task more consistently than I can tell you if it's a 1-, 2-, or 3-hour task. I need something I can quickly use on the fly in a meeting to provide a rough idea of the complexity involved, without spending lots of time digging into every detail. And because it corresponds roughly to hours/days, other developers can tell if I estimated badly as they're digging into the task, and quickly raise a red flag.
We use a Trello board and move our cards from left to right. No surprise there. Here are the columns we use:
Everything starts here as we discuss, describe, and prioritize. Highest priorities to the top. To keep a balance between new features and development, I usually try to organize into batches. We're putting 80% of our points towards new development and 20% to maintainance and refactoring. Sometimes this column turns into many columns, as we're sorting and organizing.
Ready to start
After compiling a batch, we move all the cards to this column. Developers grab a new card when they need something to work on, generally preferring the items at the top of the list.
This column indicates that work has started. We try to have relevant discussions in each card instead of Slack, because it automatically keeps things more organized. Works better than having multiple Slack conversations going on at once and or trying to keep track of Slack threads.
We move cards here when they're ready for another team member to take a look and give some feedback.
This column is for approved cards that are awaiting deployment.
Once deployed, I go back to the stakeholders and ask them to sign off on the feature. We discuss as needed until they're satisfied. Might send the card back to the left if adjustments are necessary.
Finished (and beyond)
Once the appropriate stakeholder has approved the feature, we move it here. I periodically create a new "Finished" column and rename this one with a date on it. This gives us a rough history of our work and velocity.
Occasionally, a card gets underestimated. When we realize this, we try to split out new cards from the one that has ballooned up. Depending on the circumstance, then we might keep working them, or we may move them back to the prep area and work them into the next batch.
Hope you found this helpful. Feel free to email me with questions.