Scrum is normally for teams with at least 3 developers. And there is a Scrum master and product owner around. However, the agile framework is full of gems even for one-man operations and indie developers. In the following paragraphs I will describe how I use the Scrum framework by first going through the Scrum events, how I apply them for the development of my app and then how I manage the backlog. This is not quite “Scrum by the book”, however, Scrum encapsulates very useful habits which make us humans happier and more productive even outside the work environment as personal Scrum. I’m also filling the framework here with practices I found work great for me.
I have used the Scrum framework to build version 2.0 of my app, “NotePlan”, from scratch (a complete re-write) in swift, which I had to learn in the process. I learned Scrum by introducing it into the company I worked before and got the PSM 1 certificate.
Tools
I’m using Jira. The UX is not always intuitive, but it gives you what you need (and way more) to implement Scrum for a low price. I have tried to accomplish this inside Trello earlier, but it was too messy. No matter how I did it, I quickly lost the overview. 98% of the time I use the product and sprint backlog inside Jira and add or refine the user stories. The other 2% of my time I spent in the reports at the end of the sprint.
I have also tried the physical approach using whiteboards, index cards, post-its, etc. It looks fancy, but it’s impractical. You need something digital for simple copy-paste and search functionality.
Scrum Events for One
First, a quick summary of the events. In Scrum you meet up for:
- the Sprint Planning at the beginning of a sprint to decide the goal of the sprint and pick the maximum of user stories you can handle to fulfill the goal in this sprint,
- the Sprint Review at the end of a sprint to gather feedback about the product increment you just have finished, ideally from real customers
- and the Sprint Retrospective (after the review) to reflect on how you were doing and to find ways to improve yourself.
- In between, you meet up for Backlog Refinement to keep the backlog clean and updated. This makes the sprint planning way faster and easier.
- And finally, there is the Daily Scrum meeting or “standup” to synchronize activities and create a plan for the current day.
It doesn’t actually matter if you are solo or in a team. You still can and should hold the Scrum events. Here is how you can do “Solo Scrum” as indie developer.
1. Sprint Planning
Here you set yourself a goal (good habit!) and pick all the user stories from the prioritized product backlog in Jira you think you can accomplish in the next 2 weeks (assuming your sprint is 2 weeks). This can take just a few minutes if you kept the backlog clean and up to date. The result is the sprint backlog. This is quite straightforward and Jira supports creating a product backlog, sprint backlog and sprint goal including a start and end time.
Example of starting a sprint in Jira.
All the user stories (not bugs) you select for the sprint backlog should be also estimated using story points (this number represents the relative size between user stories, usually from 1–13 and picked from the Fibonacci sequence: 1, 2, 3, 5, 8 or 13). Why story points? You can calculate your average velocity, measure your productivity and make planning more predictable. The amount of points you are getting done (and this means “done-done”, including unit tests and manual testing, etc.) in a sprint is your velocity.
2. Sprint Review
At the end of a sprint, in the Sprint Review, you can inspect the product yourself, but it’s way better if you can get feedback from your users. Instead of inviting them to a meeting (which becomes quite difficult if it’s “just” a small app) you can talk with your users via email, Twitter, Reddit, etc. to validate that you are on the right track. This deviates from the vanilla Scrum, because the review should be a single event at the end of the sprint.
Here is how I do it:
After releasing an update I often get emails with feedback right away, because I encourage users to write back in the change-log and in general. This works best if you have a beta program. Furthermore, I sometimes actively email the users to have a look at the newest increment. Since I still have the original feedback and the email address saved in the user stories, I can contact relevant users. I’m also using NotePlan (the app I’m developing) myself every day which gives me plenty of opportunities to review new features and bug fixes from the perspective of an end-user.
3. Sprint Retrospective
Here you review how the sprint went in the past 2 weeks. Is there anything you can improve in your workflow? Did the tools you were using create any problems? Is there anything better you can use to save time and level up the quality? If yes, (and you should always find something) you add it as a user story into the next sprint. Ideally, you learn and improve yourself a little bit in every sprint. For software projects, this often means unit tests, automated UI tests, continuous integration, and so on. Is there a better tool money can buy than what you are using right now? Or are there better libraries you could use?
Here is how I do it:
A real-life example of a retro I had: I have unit tests and UI tests inside XCode which I run all at least once before releasing. A big waste of time was that the tests never ran automatically with just a single click from start to end. Some failed and created even crashes, but not due to bugs or changes in the app. Rather I didn’t close a few tests in a clean way so that the next one couldn’t run independently. This meant I had to re-run those tests by clicking through each one manually and waiting until they finished. In a retro, I recognized this and fixed it in the next sprint. This saves me countless hours now and in future and I can release much faster. Next point I want to add to my workflow is continuous integration with Jenkins. To run tests automatically and much more often.
4. Backlog Refinement
This could happen when you plan the next sprint or in the moment where you process feedback. You check if the priority of the items is still correct, estimate user stories and sharpen descriptions and titles. Or add more ideas and context to existing items.
Here is how I do it:
Every 1–2 days I batch-process emails with feedback. In this process, I need to open and edit the product backlog for adding new user stories, bugs or adding just more context to existing user stories. At the same time, I’m re-prioritizing items if I notice it’s more important than currently reflected in the backlog. Often I’m following up with users on specific feature requests or bugs to find out more. This means I learn something new every other day about the app I’m building and this should be reflected in the backlog as well so nothing will be lost.
5. Daily Scrum
Here you think (or better: journal, which is also a good habit) about how the last day went and what you plan to work on today by reviewing the current sprint backlog and if there are any obstacles in the way you need to take care of. That’s an opportunity to update the sprint backlog as well and check how many days are left in the sprint.
Here is how I do it:
In my daily journal (or sometimes just in my head on a brief morning walk) I reflect briefly what went well yesterday and what could have been better (you can do this also at the end of the day). Todos I couldn’t finish yesterday are re-scheduled to today (if you need an app to help you, check out my app “NotePlan”). If a user story or bug was closed, I review the sprint backlog and pick the next one.
This is how a sprint backlog looks like in Jira with the Kanban board layout. The label showing the remaining days is quite useful.
—
That’s all, we have covered all Scrum events. In my eyes, every event carries a productive habit: 1. Setting goals and incremental planning, 2. reviewing your work, 3. reviewing and improving yourself, 4. refining and updating your plan (backlog) and finally 5. daily reflection (or journaling).
Product Backlog and How Things Get There
In the following paragraphs, I describe (in my eyes) the ideal way of filling and managing your product backlog as an indie app developer. It’s not part of Scrum how to manage the backlog, just that you have one.
The product (and sprint backlog) is where your product lives. I’m adding everything to the backlog. Every piece of feedback. Yes, everything. Because everything counts — and the more, the better. That’s what works really well in Jira. You won’t get overwhelmed by the sheer amount of items due to the prioritization of items and by using filters.
The backlog is a key part of the feedback loop. And it’s simple: The most important items are at the top. What’s important? All those tangible things you hear over and over from your users. The backlog is quickly filled, even if you abandon your old system and start from scratch if you have set up a good feedback loop.
The Feedback Loop
I will outline how it usually works for me and then go deeper into the important points:
- Get an email from a user with feedback like feature suggestions or bug reports.
- Add the feedback as user story to the backlog. Then copy the relevant parts from the email directly into the user story description along with the user’s email address (so you can write back once the feature or bug is done).
- Prioritize the user story or bug. Pro tip: bugs are always top priority. Push them to the top of your backlog. You don’t want to have bugs lingering in your backlog. Fix them asap. Feature request you hear about over and over and which fit your product vision should be also near the top.
- Eventually, you implement the feature or fix the bug which is near the top and got into your sprint. The original description by the actual user becomes extremely handy in the development process.
- Users get the update, open up their favorite email app and the loop starts again.
1. & 2. Capturing the Original Feedback
Feedback can come from users, from yourself, team members (if you have any) or any other believable sources. Feedback from actual paying users is usually more valuable than from people without “skin in the game”. The important part here is to capture the original message. Don’t try to interpret and condense the feedback at this point. You can add what you think the user means but always save the original. Save it in the description part of an item in Jira after while you create a new user story or bug. This comes extremely handy once you start developing. Also, save the email address of the user who shared the feedback. This will become useful later if you need feedback on the closed feature or bug. Or if you need to clarify anything. Furthermore, reply quickly and encourage people to write to you. Keep the feedback loop going!
Here is how I do it:
When you capture feedback you have your product owner hat on. I process feedback in batches. Means I wait until enough emails and messages accumulate, usually 1–2 days, then go through each back-to-back and give a detailed reply or clarify details. I reply to every message I receive and that normally within 1–2 days. Often a small discussion develops around a few features. I want to encourage a conversation.
User Story with original snippets of feedback from different users along with a way to contact them back.
It’s not strictly Scrum, but you can see it as part of the review. Since you usually can’t invite stakeholders and customers to a single live meeting, you need to pull it from existing users after making a release. Since you saved each piece of feedback from multiple users along with the email address, you can write them now and ask how they like it. Your users will love you for your responsiveness and fast development.
3. Prioritize
You need to do this every time you process feedback or review the backlog. This can be seen as part of the “Backlog Refinement”. As per Scrum max. 10% of the team’s time should go into this. So take your time, but don’t go crazy. The priority is sometimes a moving target. Or features have about the same priority and it’s hard to say. Just make sure the most important items are near the top. Also, estimate your user stories using story points. These are relative values describing the size of a feature. Later this becomes useful if you want to calculate your velocity (how many story points you do per sprint) and using this you can estimate when you are done with a set of user stories (like a specific version).
Now the critical part: Always fix bugs first. Ideally, there are no bugs in the backlog. If there are no bugs, you are ready to ship. You are flexible. You can add new features quickly. So fix them as soon as they come in. If you are currently in the middle of a feature, finish it and then take the first bug from the top.
Why that? Bugs have no story points. Because they belong to some user story and it means this story wasn’t quite finished (or not well tested). Also, it’s really hard to estimate a bug. Fixing it right away reduces your velocity — which it should. It gives you a more realistic value. The worst case scenario is if you develop months on end and then decide to quickly test and fix bugs near the release date. You will be surprised how long it takes. And it becomes a kind of waterfall model.
Bugs are always at the top for me. I add them right away to the sprint backlog once I read about a bug in an email from a user.
4. & 5. How to Ship Quickly and Often
The idea of short sprints and a potentially releasable increment at the end of a sprint is not to ship crappy updates. You ship quality. The “trick” is to have testing and bug fixing as part of your process. The more efficient and automated the better. This is usually solved with automatic unit and UI tests.
Here is how I do it:
Like every good programmer should do it, I write the unit test first if it’s possible (it’s easy if it’s not a UI component). I don’t just write the unit test first, I use the unit test to test the implementation while I’m writing it. What a waste of time is it to boot up the whole app and navigate to the view which uses the function you are currently implementing? It’s way faster to run the unit test. I can test most of the app in an automated fashion in less than an hour using over 160 unit tests and almost 30 UI tests. The UI tests take up most of the time and they often catch a few problems. I use the rest of the day fixing anything which comes up and a bit of manual testing just to be sure.
Try to ship an update after every sprint or even multiple times in a sprint (as long as you don’t annoy users with new downloads). Take 2-week sprints. That’s just about right for most projects. If you have engaged your users before, feedback will start pouring in again shortly after the update went online. You can be also more active and message the people who requested the features or reported the bugs you have just closed and ask them how they like the results. And that’s where the feedback loop closes.
Versions, Epics and Tags
In Jira it’s easy to filter by versions and epics by using the side panel left beside your backlog:
These are the filters I’m using right now as I’m ramping up NotePlan for version 2.0.
You can use versions for major releases you are working towards which don’t fit into a single sprint. Like a version “2.0”. Then pull in the user stories which are relevant. Remember to keep the amount low. It’s too easy to bloat it and keep on developing forever towards this version.
Epics are big user stories which you need to break down. In Jira an epic is just another filter. Bundle multiple user stories into a single relevant epic.
Here is how I do it:
I’m mainly using the versions filter. This helps me to focus on a set of user stories and defer others which I think are not that important or they take a lot of effort to implement. I cherry-pick the important + easy to implement user stories into a single version. Whatever is still important, but too much for this version, I push into the next version. If the current one is 2.0, I create a 2.1 version. If you have hundreds of user stories in the backlog, it helps a lot to keep an overview by filtering it using versions.
Originally published at www.noteplan.co on October 21, 2018.
Thank you for reading this post! Leave claps and plenty of comments! If you want to check out the app I’m building using the above workflow, check out NotePlan here.