SUP — simplified scrum for your development team

Hello everyone! This article explains how I use SUP (System of Universal Productivity) when I manage development teams. It's almost the same as your typical scrum but simplified. The reason I've created it was that some of the scrum rules didn't make sense to me or the teams I worked with.

Why would anyone need a simplified scrum? Well, in case if you follow all (or most of) the scrum rules and you still find the team productivity suffering — this article is for you. Or in case if you see that you spend more time maintaining the scrum system rather than getting value out of it.

I successfully implement this system in every team I work with and everybody seems to like it more.

Rules of SUP

1. There are only 2 recurring team meetings: one hour on Monday and one hour on Friday. On Monday we plan what the team is going to be working on this week, on Friday we retrospectively analyze what we accomplished and in case we failed to accomplish a goal we come up with a solution on how not to repeat the same mistakes.
2. Work is divided into "Sprints" that last 2 weeks.
3. Once every 2 weeks our Monday meeting is also a sprint planning meeting.
4. When a sprint is started, its tasks are frozen. In case if there are new tasks — they go to the backlog, not to the current sprint. In case if a task isn't completed within this sprint, it goes back to the backlog. Again, the sprint's set of tasks is frozen after you start the sprint — nothing goes in.
5. There are only 4 columns in the sprint Kanban-like board: "Backlog", "Sprint", "Working" and "Done". "Backlog" contains all the tasks, "Sprint" — only the tasks for this sprint, "Working" contains the tasks that people work on right now, "Done" contains all the tasks that are done.
6. You only move tasks to the "Done" column when they are completed, tested and ready to be released to production.
7. Every task should be actionable and as small as possible. No more "make a button look better" or "fix the login". Instead, you should set tasks like "increase opacity from 50% to 80%" or "move the button 10px to the left".
8. There is a point system in place — every task can be worth 1, 2, 3, 5, 8, 13 points. 1 can be done quickly, 13 will be a task worth 2 weeks of development time. The catch is: you can only add a task to the backlog if it is worth at most 1 point. Yes, if you have a larger task — first, break it down, then add it to the backlog.
9. There is no division between technology teams (like backend, frontend, mobile, etc.). You only have one backlog, from which everybody grabs tasks. In case if your mobile developer is afraid of touching a server, you have to fix this issue before the sprint.
10. Every task from the sprint column gets assigned to the person responsible for it. No more loose tasks. Every task should have a person assigned to it.
11. After the tasks are distributed, everybody assigns deadlines to all their tasks, ideally, you will be able to create a timeline of the sprint, and know exactly what will be done when.
12. Every day the manager should check in with every team member on what they did yesterday and what they are going to do today. It shouldn't take more than two minutes per person — don't discuss anything during this meeting except for what was done yesterday and what to be done today.

That's all! You don't need anything else at all, no more metrics, just constant progress. The SUP methodology works well with the concept of Epic Boards (read more on them here) that helps to strategically focus the whole company. SUP will be the team layer of an Epic Board.

Hope this article helps you to redefine scrum in a way that works the best for your company. Remember: no management rules are set in stone. Modify, optimize, experiment. Let me know if you have any more questions in the comments below. Cheers!