ScrumDo is another online tool for managing work. It competes in the space of tools like LeanKit, Jira Agile, Kanbanery, SwiftKanban and a host of other tools from other vendors. The differentiation it appears to me, is that ScrumDo is slanted to a (outright) ScrumBan view of the world, combining aspects of Scrum and Kanban in what could be a much stronger product than some other offerings out there (my experience is only with LeanKit, Jira Agile and TFS/Visual Studio – not a huge amount :)). You could run a Scrum, Kanban or a ScrumBan – and you can in other tools for that matter, but the features in built in ScrumDo make it appear or feel more targeted to this.
Here in Part 1 of a series of posts I describe the setup of the first iteration of a project I’m currently running. In a previous post on LeanKit, I noted that I lacked a proper breakdown of tasks for big items on my Personal Kanban that was causing some morale issues – although I did get to end with flying colours, it’s not a way of working I recommend.
Note: I include many screenshots. I recommend clicking on the image to get a clear view if you so desire.
Cleaning up the Previous Board
I did a board for the previous project but it fell into disuse. I decided to clean it up. The standard board presents two horizontal lanes, an Expedite Lane which anyone from a Kanban background will recognize and a lane for the current iteration. Here’s what I started with and you can see the expedited column is blank. It’s hardly used and I didn’t want to use it so a later view you will see that I removed it.
I used the Iteration Planning Tool to move items, but you can also use the above view:
Cleaning up the Board – the Board Editor
I removed the Expedite column in the Board Editor, a view of which is shown here. Subsequent to this I’ll show later on some other edits that include WIP limits, effectively ScrumBan-ing the board, and adding policies under the columns like Definition of Ready for stories and Definition of Done for development tasks.
Epics and Stories
The first thing to do was create the Epic and Stories. I’m following standard scrum backlog grooming practice and I created the Epics and Stories. As this a project to create course material for an ICAgile accredited course for my company, About Agile, the Epics and Stories followed the layout of the ICAgile learning objectives for the most part. Easily filled in – not a big Release Planning session required for this project 🙂
There are a number of views for creating Epics and Stories. Here is the Backlog view:
And here’s from the Epic Planning View:
With a Release plan created (though Epics and High Level Stories and no more) it’s time to create the first sprint/iteration. The first iteration was already created as shown above and is also a way to setup an iteration. There is also some setup that can be done – interestingly one can set resource availability in hours – I wonder if this fits in with #NoEstimates 🙂 , something for later. The steps correspond roughly to part 1 of sprint planning as you’ll find in the scrum guide.
Along the way you may find that you need to change things around. For instance I needed to to convert a story into an Epic (I’m playing multiple roles being the only person on the project – PO and Developer and ScrumMaster):
I also had to move a story between Epics. This can be done in the Edit Story view. Notice standard Fibonacci Series relative estimation can be changed here (as well as elsewhere):
And also through a specific view that converts a story to an Epic. In this example I found I needed further breakdown and hence converted the story to an epic:
Sprint Planning Part 2 – Some Task Breakdown
Here I’ll show some view that allow the first few items of the sprint to be broken down. I don’t break down everything as the July 2013 version of the Scrum Guide guides us to do. I just setup enough to get going and start producing, also leaving some room for the innovation. This view shows I’m actually working on the sprint planning tasks:
And this one is showing how desperately hard I’m trying to think of the tasks that may be required for a task. Inevitably there will be something I missed:
and as always – I try and use a pomodoro/tomato timer – I sometimes forget that as well. Here I’m taking the time to take a break during sprint planning, but maybe if your doing this in a group you’d space the pomodoro to longer than 25 minutes:
Done some editing of the board whilst I created the Sprint Plan
Here I present some editor views. As I was creating the plan and learning the features available in ScrumDo I changed things to suit the desired way of working. Here I removed the Expedite horizontal lane and added WIP limits. Most columns use points for limits except the Done columns which are using card count to force a pull into the next column of the value stream. Will see how that pans out.
In this view I’m adding a Policy and a WIP limit for the TODO column. This view is accessible via the board editor:
So I got to the end of editing the board and sprint planning and the board took more shape with the first 4 tasks, the most important, having been broken down:
Advisable to have a Sprint Goal
Yes you need a milestone to aim for and I recorded mine as part of the sprint planning task and used the time recording view to keep track of the time I spent. As far a time spent, I’m not really sure I want to 1. Give a time estimate and 2. Record it. Fighting off Parkinson’s Law and Student Syndrome is already hard enough. Time estimates can be taken as targets and both of these dysfunctions can kick in.
Extras: Policies show up as tool tips
This policy is quite big and not easily view-able. Not a big issue.
This one looks better, not so big:
So at the End of the Day
So I did my sprint planning and fixed up the board as shown above in the selection of screenshots. I made a start on the tasks and found that having the smaller milestones and thinking about tasks drove more satisfying outcomes. The experience of the previous work, which I’d not done before, was a good input and I have adapted from those experiences. Having something to aim for what certainly helpful on this first day.
New projects almost always start off a bit haphazardly as all participants find their feet. This really is dependent on how new the domain is and team forming attributes of a new team The trick to to reflect and adapt, something all too often forgotten or put in the too hard basket. It’s OK to feel unsure at the beginning, but don’t let this drag on. Take action to remedy the situation. It may take several goes at it, but as long as a culture of safety exists, you should be able to take out some very valuable lessons and this is very important to build further from.
Here’s the board at the end of today for this project (BTW: this task, to write this blog, is on my personal board and not this one :))
In subsequently posts I’ll describe new features of ScrumDo as I come across them. It will interesting to see what metrics and reports I can get out of it.
Note: You can now read Part 2 of the series.