My First Agile Project Part 8: 9 Things We Disliked (and Liked) about ScrumWorks

October 20, 2008 by mattgrommes

Picture courtesy of Danube and me

This installment of My First Agile Project is going to be a little different than the previous ones (Table of Contents for the series available at the end of the post). Today I'm going to tackle the topic of tools. During the first year or so of our project we used ScrumWorks by Danube. It was brought to us by our vendor along with the Scrum methodology. After our license ran out we didn't like ScrumWorks enough to get our own license or even go with the free version, which I'll go into more detail about below.

For our last couple of sprints, we've been making due with a whiteboard and evaluating other tools. The one I like the best and we'll probably be going with is VersionOne, which I'll be talking about in more detail next week. Honestly VersionOne makes ScrumWorks look old-fashioned and barely functional. I had a list of things I didn't like about ScrumWorks and one of the first things I noticed during my initial demo was that VersionOne didn't do any of those things, obviously a big selling point. This week's post is that list of pros and cons about ScrumWorks.

Choosing a tool can be very important in a lot of software development and choosing where to put your backlog and tasks is extra important to Scrum. Since the whiteboard/corkboard + stickies/index card approach is basically free, you want to choose a tool that gives you some extra benefit. Read on for my team's pros and cons about ScrumWorks and hopefully it'll provide some insight on this important decision.

What we liked about ScrumWorks

The first thing I should say is that we started using ScrumWorks over a year and a half ago and I only recall doing one update so my experience might be out-of-date. I didn't bother looking at ScrumWorks again when looking for a new Scrum tool. Also, these are my and my team's opinions only and I'm not affiliated with either Danube or VersionOne beyond using them.

1) Gave Us Structure
As I said, our vendor brought ScrumWorks with them along with the Scrum methodology when they came to work with us on our project. Since this was our first exposure to Scrum, bringing a tool they were familiar with was a good idea. If we hadn't had the guidance on the process that ScrumWorks brought just by having a set workflow and screens that asked for the important information for backlog items and tasks, it would have been a lot more work getting going. If we'd had to figure out what needed to go on cards, which cards went where, how to make a burndown chart, etc., it would have taken a lot of time.

2) Did the Basics
We also liked being able to see our tasks and make changes online, run reports, make graphs, etc. Being essentially lazy, having a program automatically make the burndown chart alone is worth a lot to me.

An aside about Burndown charts

One unrelated note on these automatically generated burndown charts: make sure your upper management doesn't fall too in love with them. We had problems early on with our management not understanding the process and using whether or not the line on the chart was going up or down as their only view into how the project was going. Managers love graphs and will (ab)use them if you let them. You learn things and change estimates and the line goes up. This is fine.

What we didn't like about ScrumWorks

This is the bigger of the 2 lists, unfortunately. ScrumWorks gave us the basic functionality required for a backlog/task manager. How it did that is where the annoyances came from. Now, these things might not annoy you and I'm sure they made some of these choices on purpose but they didn't suit our team. Tools are very individual and I think ScrumWorks is pretty popular so other people must love the heck out of it. That was not our experience.

Picture courtesy of Danube and me

3) Too Many Required Fields
The first annoyance we ran into was that ScrumWorks makes too many things required. To enter a backlog item you have to do your difficulty estimate, and enter a value for business benefit before you can save the item. This gets in the way of just entering things into the product backlog so you don't forget about it later. Estimating difficulty should be the team's job (or at least the team member responsible for the item), not the job of whoever enters the item. And being forced to enter a benefit in just so ScrumWorks can do its priority calculation (it gives you a ratio of difficulty to benefit) was extra annoying because we never used the calculation it gave. Since our project was to replace an existing system, everything we entered at first was functionality we had to replace so how were we to determine the benefit? We tried at first but it just wasted time in planning meetings. At the end we were just entering 5 for everything it required us to fill in just to get past the screen.

4) Too Much Required Workflow
In the same vein, you also have to estimate tasks as they're created and you're not allowed to assign a task to somebody before you put the item into a sprint. It's one thing to suggest people follow the proper procedure, it's another when your tool forces you to do things a different way than you want to for no reason. I can't tell you how many times we were forced to stop our planning flow to do things the way ScrumWorks wanted us to.

5) Can't Split Items Between Sprints
Another big irritation was the inability to split up items between Sprints. If you don't finish a task during a sprint, you're forced to move the whole backlog item to another sprint, losing the history of when you first did what. The first chunk of our planning meetings was spent going through unfinished items, checking if they were actually incomplete or if we just forgot to close them out, and moving the item to the current sprint. I was beyond pleased to find that VersionOne gives you an easy way to split things up between sprints.

Picture courtesy of Danube and me

6) Forces You To Use 2 Different Tools
ScrumWorks is actually 2 tools, a web-based taskboard and a regular desktop application for sprint and backlog maintenance. I can only guess that either they, unlike VersionOne, didn't think the web could handle the maintenance interface or they added the taskboard web interface later. In either case, it's jarring to have to go from the taskboard to a different URL to launch the desktop app for certain things. But the web interface is the one you use most of the time so that's not a huge concern.

7) Can't See Only Your Tasks
First is that you can't just see your own tasks and items. All the items are shown in a long list and you just have to scroll or search for yours. They're highlighted with a color but you can't just show yours. This led to a lot of problems with people not knowing they had been assigned something or forgetting to update a task because they skipped over it. Just because you can't sort or filter a whiteboard with index cards doesn't mean I shouldn't be able to filter a web list of tasks. That's a head scratcher of a decision to me, it makes no sense.

8) Web Interface Became Unusably Slow
The more sprints we went through, the slower the web interface became. I won't guess at how they designed the thing to say why that might happen but it was almost unusably slow after 9 or 10 sprints.

9) No Way To Find Each Team Members' Hours
There's no way to find how many hours of work you have assigned to you. It's not in the web interface and if it's in the desktop app we never found it. What we always had to do was export the sprint to Excel and use the Filter feature to show each person's tasks, then add up the hours. Obviously not ideal.

Conclusion

I hope that gives you a feel for what we liked and didn't like in ScrumWorks. It does what its supposed to, giving you control over items and tasks and whatnot, but the way it does those things ranges from no-frills to annoying to infuriating. It was never really a question on our team if we wanted to continue using it or not, we even considered just writing our own basic version. As I said, our experience is a year old now and they might have revolutionized the product for all I know. But for now, we're all glad to be off ScrumWorks, even if it means being without a good tool for the time being.

I meant this entry to be a review of both ScrumWorks and VersionOne but in the interest of not putting any more of my readers to sleep than I already have, I split this up and will give each tool the space they deserve. If you're dying for a VersionOne review before next week, I give it a big thumbs up and encourage you to talk to them about doing a demo. They let you use it for 30 days and I found that a big help. They also have a ton of videos and tutorials that give you a feel for using the tool. More on our experience next week! Thanks for reading.

If you have experiences with ScrumWorks you'd like to share, please do in the comments below.

My First Agile Project Series
Part 1: Doing 80%
Part 2: Inception & Planning
Part 3: Viral Videos and Bad Jokes in Scrum Demos
Part 4: How to lose credibility and jeopardize your project with lack of management buy-in
Part 5: Our Top 5 Agile Mistakes
Part 6: The First End of Our Project
Part 7: Adventures in Agile Testing

Permalink