This is the fourth article of our Scrum Tool Series in which we evaluate the status quo of Scrum Tools available right now. Previously, we examined JIRA, Mingle & targetprocess. Today we will have a detailed look at Scrumwise, a company that is quite a new player on the field. A promising one.
Functionality
When I fired up my personal Scrumwise for the first time, I nearly spilled my cup of tea on my keyboard (yep, I drink tea although my test stories for Scrum tools tell you something different). You might ask why? Because I got a loading bar like we know from these über fancy websites made in Flash some years ago. Yes, those sites that took ages to load with no interesting content on it at all. Luckily, Scrumwise uses Flash how it should be used: to create fast, AJAX-like pages. After the (fast) preloading was done, Scrumwise offers a very minimal and simplistic user interface, at least at first glance. The setup approach has some similarities with targetprocess, although this time no wizard tries to bewitch me. Instead, a well-known tab-based interface guides me through the whole process. We start by creating a new project in the “projects” tab, which offers us a blank interface and one single button that asks us to add a new project. The only thing we have to do is give our project a name and click the add button – et voilà, our project is added, indicated by a nicely animated blue bar.The next thing we have to do is add some people to our project. Once again, the interface is minimalistic but sufficient. Scrumwise offers us two possibilities: adding a team and adding a person. The former is a necessity to perform as a project without a project team makes little sense. After having done so, we can start to create new users (again, for both dialogs the above said holds true again. Only necessary information has to be entered). Different areas indicate places where we can drag and drop our newly added people. For example, we can add a certain user to our project team, but we can also move him to the product owners or stakeholders (I assume that by stakeholders the customers are meant). As much as I like these different areas, it remains unclear why there is no special group for the Scrum Masters.
The following step is to fill the backlog with user stories. Again, we click on the corresponding button to do so. Scrumwise offers us to choose a type for the story (e.g. feature, bug, spike, other) so which type should be chosen for a common story? I would tend to “other” as “feature” might be confused with a much higher-level hierarchy item; an extra “story” type would make more sense in my opinion. Back to the user stories. Scrumwise ask to estimate them in story points, which is a good thing. Still, we have to add some tasks, and we can do that by double clicking a story. Tasks are estimated in days by default, although this setting can be changed to hours or again points. Personally, I would say that hours are more suitable, but again that is a matter of choice. Tasks appear as little, yellow post it notes within the story details, stating their estimation, their progress and the assigned user (as soon as an user pulls the task). The backlog items can be prioritized quite neatly by drag & drop them to the right position.
After that we are ready to create our first sprint, yeha! Click the “add a sprint” button and Scrumwise will present you a little calendar where you can choose the start and the end date of the sprint followed by an input field where we have to state how many days/hours/points the sprint can last (depending on the choice made for estimating tasks). Then its time to add some stories to the sprint, again by using drag & drop. However, one can alter the priority of the stories, although we prioritized them – an issue I would suggest to change (or at least giving the user a choice in the project settings regarding which type he or she prefers). After finishing adding the stories, the user is confronted with a calendar popup again – but didn’t we specify the date when creating the sprint? This is correct. I had a quick conversation with Scrumwise regarding that feature / bug and their response makes sense, as it is really a feature, reminding the user about his date choice so that he can think about it after having added some stories. Scrumwise promised to think about whether making this setting changeable, which is nice to hear. When talking about the calendar, I would love to see a colored marker that indicates a 2/3/4 week sprint; quite handy if the sprint takes for example the last two weeks of a month and the first two of the following month.
Coming to the task board, it just works the way it should work. On the left side the stories are listed and they change their background color to green as soon as all tasks are completed (nice!). If a user drags a task from “To Do” to “In Progress”, the tasks gets automatically assigned to him or her (even nicer!). Unfortunately, I could not find a way to alter the columns of the task board – by default a “To test” column is available which I would like to remove. No chance. But there is one single feature that makes Scrumwise a shining star and that is automatic update on all screens if one user changes the status of a task. In other words, If I move a task from “To Do” into “In Progress”, this change happens on all other screens as well. Even better, a nice animation is included. KILLER!
Last but certainly not least we have reporting possibilities – a burndown chart that measures the burndown of story points over time, which is created automatically (and of course updated automatically). That’s it, no other kind of reports. Might be a showstopper for some fellows, but I think Scrumwise is trying to make a point by focusing on what we need in Scrum and discarding everything else. We don’t have Kanban support, no detailed access control and no event-based notifications. Features I like to have, but if you think twice about: do we really need those features? The answer of Scrumwise is a clear no and I tend to agree. Still, Scrumwise offers to export stories and tasks (CSV format), a detailed time registration (disabled by default) and declaration of bugs. Undo functionality is not available, but that holds true for all Tools that use AJAX.
Usability
Scrumwise does support some keyboard commands, although not as much as for example JIRA. As mentioned already above, the interface is quite simple and lightweight, but it is not as eye-candy as the one of targetprocess. Buttons could be a bit bigger, but they catch the users attention. A point of criticism is that the backlog priority is a bit useless as it can be changed nevertheless when creating a sprint. Still, I my opinion, Scrumwise is self-explanatory and it is clearly arranged. That’s thus a double yes (hello targetprocess!).
Performance
Performance could be seen as the second killer argument of Scrumwise: it feels like 100% AJAXed (due to Flash). What this means? This means that everything in Scrumwise feels like you would run a local piece of software on your local machine. I was already satisfied with the amount of AJAX targetprocess does offer, but Scrumwise boosts this experience to a whole new level. On the top of that, Scrumwise does only offer to use their software on their very own cloud platform. Thus when testing Scrumwise, I did not benefit from the speed a local server might deliver. It goes without saying that the performance does not change when setting up my smartphone as hotspot again for simulating a lower bandwidth. Performance-wise, Scrumwise has raised the bar.
Resources
When talking about resources, Scrumwise is pleased quite fast. According to their help, any major browser should do the trick. Nevertheless, I assume that the browser version should be as recent as possible, as Flashplayer Version 10.0 is required. For some people that might be a killer argument to not use Scrumwise – due to the fact that it relies on Flash (as Flash is quite vulnerable). Regarding display resolution Scrumwise works perfect on a screen that has at least a pixel width of 1145 and a pixel height of 550. As Scrumwise is cloud-only, no local servers are supported.
Interface
The interface is quite standard. We have a header with tabs, which provide their corresponding information, like backlog, task board, etc. Without the logo, the header bar could be 
smaller, but that’s a minor issue. I already talked about speed; I haven’t seen a faster, browser-based tool till now. Scrumwise can mark user input errors, however it just marks them red instead of giving a tooltip with some information regarding what went wrong. A story can have more than 100 story points, in fact Scrumwise allows to define up to 9999 points before an error is given. Another issue is the fact that a task can be directly moved from “To Do” to “Done” which is not my personal favor of handling tasks. Last but not least, a full screen mode for the task board is not available.
Motivation
As stated before, when someone moves a task, everyone’s screen will be updated automatically which greatly helps to avoid wallboard blindness. If this feature is a little bit enhanced, it will also work on big screens. Like in other tools, the users can comment tasks and stories, but commenting is not as extensive as in Mingle where also a change of status can be commented.
Costs
The costs are as simple and plain as the rest of the tool: you have to pay 6$ per user per month. No local hosting, everything works only in the cloud of Scrumwise. With such a price, Scrumwise is more expensive than JIRA, but cheaper than targetprocess.
Advantages
- Speed
- Simple
- Automatic update of tasks
Disadvantages
- Flash
- Less (but wellthought!) features
- Costs
The curtain falls
Scrumwise is the ideal tool for companies that want to do Scrum and just Scrum. No unnecessary features – instead Scrumwise offers an amazing fast user experience. Scrumwise is like a racing car: every feature that causes unnecessary load is discarded, but for its purpose it works just fine. Next time, I will have a look at AgileZen.