Stupid Simple Scrum using ClickUp

Lots of people banter back and forth about the “one true way” to do scrum and agile software development as if there was a golden textbook that fit every team.

While there’s not one true way to do scrum, here, I’ve devised what I call “simple stupid scrum” using a tool called ClickUp. I like ClickUp because it has a clean design, and I find its “upward” nature (the stories move from bottom to top) to make sense.

Step 1: Setup ClickUp

When setting up your ClickUp project, you’ll do these two specific things at the start:

Click the + button to make a new project.

Create it as a “List” project

You will name your new project here.

Next, we’ll start by customizing the statuses of your stories.

Choose “Manage Statuses”

On the next modal screen, be sure to select “Use custom statuses”

The list comes with a default “TO-DO” which you will want to rename to Idea now. (Keep it a grey color.)

Then, set the statuses to this list: Idea, Short-Term, Up Next, In Progress, Buggy, Blocked

You do this by clicking the + icon to the right of the “Active” statuses list.

Scroll down to where there are special statuses for Complete and Closed.

Add a Complete status and call it “Completed”

Re-name the existing (default) status in Closed to “WON’T FIX (CLOSED)”

Your finished result should look like this. Make sure that the status list is in this order from top-to-bottom, and drag them to re-order them. (I personally like these colors too but you may make any colors of your own choosing.)

• Setup an custom field called Estimate with a Field Type of Dropdown (this makes it a simple drop down) and a field name of “Estimate” and an options list of: Sand, Pebble, Rock, Boulder.

Here’s how to do it step-by-step

First, create a dummy task called “test task”

Then, open the task by clicking on the Edit icon, and look to where it says “Custom Fields” Create a new custom field.

You will be prompted to choose a field type. Choose Drop-Down

Next, name this field “Estimate”

Then add, four options: Sand, Pebble, Rock, Boulder

Step 2: Have the Planning Meeting

When you have your weekly sprint planning meeting with your stakeholders or product managers (which should be a conversation between the developers and the stakeholders), here’s what you focus on:

• Put new ideas into the “Idea” bucket

• Discuss moving items from the “Idea” bucket into the “Up-Next” bucket. As you move them, the developers assign the story with an estimate: Sand, Pebble, Rock, or Boulder. Anything more significant should be broken down into smaller stories.

The Up Next bucket should contain the number of stories the developers think they can do in the next week (sprint). If the stakeholders think more essential stories should be up next, then you re-arrange the two buckets so that the developers believe the Up Next is achievable in a 1-week sprint. The Short Term represents the next 2 to 4 sprints (or 2 to 4 weeks), approximately.

Then, you stop there. You stop the meeting when that goal is achieved.

As I have discussed in previous posts, I am against the practice of assigning stories to developers. I believe assigning stories to developers is given to heroic management structures and creates heterogeneous teams. Ideally, while your team may be somewhat heterogeneous when you hire them, the ideal trajectory for a development team is for all members to be treated as equally capable of picking up any story in the queue. Of course, there will be exceptions when you must give specific stories to certain developers. But you should become cognisant of your own internal biases and, ideally, avoid this practice except as a last resort to encourage the cross-sharing of knowledge.
For this reason, I always ensure that everything in the Up Next bucket stays unassigned unless or until the development team itself discusses assignments.

Step 3: Daily Standup

There are two ways to run daily standup. (I prefer Method #1, but I am also presenting Method #2 for completeness).

Method 1: Developer-by-Developer

• You go around the team, and each developer says:

• What they did yesterday (see “definition of done”)

• What they are working on today

• Anything that is blocking them on what they are working on today

Each developer’s standup should be about 60-120 seconds and if it goes on longer unnecessarily, the other developers should hold out a rubber rabbit and wave it around to indicate that the discussion is going down a rabbit hole.

Everyone should stand while the stand-up is going on to ensure people are paying attention and are focused on being brief.

Method 2: “Down the Board”

In Method 2, you go down the list of stories in the In Progress ClickUp board instead. This method can cause developers on large teams to not participate much if their stories are small or they pick up stories slowly. The other downside to this method is that the details of each and every story become unnecessarily broadcast to the whole team— which may or may not make sense for you.

This method is fine for teams with high cohesion and accountability who dislike going around developer-by-developer.

Step 4: What happens between Idea and Short-Term

The final step in this simple scrum method is to get the stakeholders to take responsibility for what happens between ideas and when things can get started.

The developer must tow the line here, and demand that only stories that meet certain criteria be moved from Idea into Short-Term.

Remember, Short-Term means “2 or 4 sprints out.” It does not mean “next sprint,” which is what Up Next is for.

The requirements I usually like to see to move a story from idea to Short Term are:

• Stories are written (if you want a primer on effective story writing, see this post.)

• If they need designs, designs are ready & attached to the story.

• Any pending or pre-known blockers are removed

If and only if stories meet these requirements, then can be moved into Short-Term

Additionally, Short Term represents only 2 to 4 sprints worth of work (approximately), so stories should get moved back and forth as priorities shift.

Conclusion

There you have it, my recipe for Stupid Simple Scrum. Various teams of differing sizes may need certain tweaks, but I find that often, too much ceremony and process can overburden without adding value. The point of the “Stupid Simple Scrum” is to be only the essential parts of the scrum that you need, no more, no less. KISS, as they said in the US Navy so many years ago.