Managing Scrum Projects with LiquidPlanner

So, your team is doing software development using Scrum (or some flavor of Scrum) and you want to know how to use LiquidPlanner to help out. Well, here’s one way of doing it. (Note – this works for some but your mileage may vary.)

What is Scrum?

Well if you don’t know then you can go here and use it as a starting point. Once you know, come on back.

With that out of the way we’ll move on to building the project.

Building the Project

Open your space and click the projects radio button in the header.

Click the “add” button on the action bar to bring up the add menu and select “Add a Project”.

Name the project whatever you’d like, in this case we’ll call it the SSCB (for Superconducting Super Colliding Button). Assign it to the Product Owner and click save.

At this point you can save yourself some time by using the keyboard shortcut for adding a project by hitting Ctrl-Shift-Enter to add new subprojects under the main project. You’ll need to add 3 of them.

1. Bugs
2. Sprint 1
3. Product Backlog

You can omit the Bugs subproject if you are using other software for bug tracking. Under the Sprint 1 subproject add two sub-subprojects (and at this point I’m going to stop using the prefix “sub-”) and call them “In Process” and “Sprint Backlog”. Your project tree should now look something like this…

Building the Product Backlog

Now your product owner can add items to the product backlog without randomizing your team. The product owner should try to keep the items (both the workitems and the projects) in priority order. That way, when it comes time for the sprint planning meeting, everything is ready to go.

Building a Sprint

• In Process
  and
• Sprint Backlog

So it looks like this…
<new_sprint_project>

Now you’re ready to load the sprint up during the sprint planning meeting.

Sprint Planning

Daily Scrum

1. What have you done since the last daily scrum?
2. What do you plan on doing between now and the next daily scrum?
3. What impediments stand in the way of meeting your commitments to this sprint and this project?

Since you have the sprint open in front of you (projects view), you can see at a glance all the items in this sprint.

Set the filters to…
project = this sprint
category = all categories
owner = whoever is giving their update
status = active items

If you are blocked on anything, set a manual red flag on that item so the rest of the team and your scrum master can see that there’s a problem.

Sprint Review

At the end of a sprint you’re ideally supposed to do a demonstration of the functionality delivered by the team during that sprint. That’s the sprint review meeting (not ot be confused with the sprint retrospective).

After the end of the demonstration of functionality, I recommend a ceremonial “done-ing” of the sprint. The scrum master asks the team if there is any reason not to mark the sprint as “done”. If there are no objections from the team, the sprint folder gets marked done. If the product owner or stakeholders object, they should feel free to add high priority items to the product backlog to be addressed in the next sprint.

Sprint Retrospective

After the sprint review and before the next sprint’s sprint planning meeting, the scrum master holds a meeting for the team to discuss the lessons they learned during the sprint and improvements they want to make to their development processes. This is a great time to have the full history of what went on during the sprint that LiquidPlanner provides. Just release all of your filters except for the project filter. Set the project filter to just the sprint in question.

Conclusion

Scrum is great and there are about as many flavors of it as there are of vodka (which is also great). This describes one particular flavor of scrum.

You should feel free to adapt it as you see fit. For example, at LiquidPlanner we keep our bugs in the sprint folder. That makes the sprint folder look a bit different, but it lets us track in which sprint a bug got fixed.

Hope this helps!