• The ability to close projects via the Project dashboard. Closed projects don’t appear anymore  in the “Project” dropdown menu anymore.
• Upgrade of some Javascript libraries (Prototype 1.7 and Scriptaculous 1.9) that will improve support of IE8 and IE9.

In case of Javascript issues with the new libraries, you can switch back to the previous ones by editing “index.php” and updating the following line:

// In case of issue, switch back to '1.6.1'
define('PROTOTYPEJS_VERSION', '1.7');

Moving forward, I expect releases to be smaller and hopefully more frequent.

Sprint management has been rebuilt, with an assistant approach to configure a new sprint. The generation of the burndown chart is now more flexible: you can define the working days of the sprint (i.e: if there are some bank holidays, or trainings, or…) and the hour of the day when burndown charts will be generated (i.e: you may want to generate them just before your daily standups).

New homepage:

Product backlog management:

New burndown chart configuration screen:

This 0.71 release has been really long in the making… You may have noted I have skipped 0.60 : in previous posts, I announced 0.60 as a release to implement a proper login solution for theSCRUM. While I started working on it, it appeared to be quite a boring task; and when the idea of a new user interface came up, I became too much excited and switched to it while forgetting the login stuff… It’s never good not being focused when developing software product; and considering I’m pretty busy these days, I believe the future of theSCRUM will be smaller releases and the publication of the source code on GitHub in hope people will contribute to it.

Getting Real by 37signals is a must-read for those writing web applications. The book was first published in 2006; and despite the progress and changes in web development since then, this remains an accurate source of inspiration. I’m re-reading it these days, and the following section entitled “Make Opinionated Software” kind-of summaries the state of mind I have when developing theSCRUM:

Some people argue software should be agnostic. They say it’s arrogant for developers to limit features or ignore feature requests. They say software should always be as flexible as possible.

We think that’s bullshit. The best software has a vision. The best software takes sides. When someone uses software, they’re not just looking for features, they’re looking for an approach. They’re looking for a vision. Decide what your vision is and run with it.

And remember, if they don’t like your vision there are plenty of other visions out there for people. Don’t go chasing people you’ll never make happy.

A great example is the original wiki design. Ward Cunningham and friends deliberately stripped the wiki of many features that were considered integral to document collaboration in the past. Instead of attributing each change of the document to a certain person, they removed much of the visual representation of ownership. They made the content ego-less and time-less. They decided it wasn’t important who wrote the content or when it was written. And that has made all the difference. This decision fostered a shared sense of community and was a key ingredient in the success of Wikipedia.

Our apps have followed a similar path. They don’t try to be all things to all people. They have an attitude. They seek out customers who are actually partners. They speak to people who share our vision. You’re either on the bus or off the bus.

The goal of theSCRUM is not to be the swiss knife of Agile teams, or to be a challenger to advanced solutions like VersionOne. If I should describe the vision for theSCRUM:

• Reduce the time spent on the tool, focus agile teams on the product they are building, not on the tool they are using,
• Just the necessary level of features: management of product backlogs, sprint backlogs if teams don’t want to use post-its, and product roadmap. That’s all.

The next version is coming soon, with improvements of the current tools… Stay tuned!

Support of bugs and impediments

It is now possible to track bugs and impediments inside theSCRUM. Bugs and impediments are considered as new types of user stories, and can only exist as standalone stories (it is not possible to put some bugs or impediments inside an epic). Bugs can have an URL attached to them, to link to your bug tracking system.

If you are not familiar with impediments, Agile Commentary suggests the following definition: “anything that delays a team member from working as efficiently and productively as possible“.

Thanks to Décio Penna from Level Up! to have initiated the discussion regarding bugs and impediments on the forum and to have contributed to the source code of theSCRUM!

Moving stories inside / outside epics

It is now possible to move standalone stories inside epics, and to detach stories from epics. This was a recurring need from the various product owners at Kelkoo, who cannot always know from the beginning the importance or size of a new story. Those new options are available from the “edit story details” panel.

Project statistics

A new statistic dashboard – still a work in progress – has been added to projects. It displays graphs to track the “Worked hours by sprint“, the “Story points by sprint” and the “Productivity by sprint” (productivity being calculated as the number of worked hours per story point).

Thanks to Jerome Colin from Kelkoo to have coded this part.

Upgrading

If you are upgrading from theSCRUM 0.5, please read the upgrade guide. You can use the discussion forum to report any feedback / problems with this release.

What’s next?

I still aim to simplify the installation and upgrade process of theSCRUM, though I didn’t do much progress on this yet. Also, I think it will be soon needed to do a bit of refactoring (especially on the Javascript side of things) and streamline the experience in some areas. The challenge of the next versions is indeed to not alter the user experience by adding tons of new features, but try to improve it.

The next version (0.6) is in the works, and will be focused on stability/robustness enhancements. I would also like to improve the installation process, to avoid new users configure .htaccess / crontab and so on… This is obviously hard work to do, but hopefully some first improvements will be integrated into 0.6.

When will theSCRUM 0.6 be released? No target date; it will be released once enough improvements are done to justify a new release. In the meantime, feel free to contribute on the forum to request some enhancements, report some bugs… Those feedbacks will likely help 0.6 to be released sooner than later!

• A well-thought user interface enables Scrum teams to reduce the time spent on the tool; and keep them busy on the product they are working on, not on the tool itself.
• theSCRUM has just the necessary level of features: management of product backlogs and sprint plannings; for multi-project organisations, tools to manage the product roadmap are available. No unnecessary features, no fat.

Why has theSCRUM been designed?

I’m in the software industry for about 10 years. Ten years ago, I have been teached how to do software project management using the V-Model, Gantt charts, Microsoft Project… Three years ago, while working at Yahoo! then Kelkoo shopping comparison website, I have been initiated to Agile and SCRUM. Since then, I have interacted with the various engineering teams at Kelkoo, seen how they were progressing on this Agile journey.

Especially, I have become interested in the way those teams were using tools to support the Agile process. I have seen them experimenting with all kind of tools, from Excel to Google Docs spreadsheets, from internal tools based on Bugzilla to open source tools based on Trac, from open source to commercial solutions… Few have experimented with sticky notes, due to the distributed nature of most projects (product owner in one location, team in another…). In the end, those agile teams spent a lot of time “dealing with the tools”, and then were distracted from the important part: the product they were working on.

As manager of a team of product owners, I then started the development of a tool to ease the management of product backlogs. My main focus was to create a user interface that lets the product owners focus on the backlog itself. Making usage of AJAX interaction, in-line editing and advanced Javascript, the first version of theSCRUM was born. I have been pleased to see product owners quickly adopting the tool; then the Scrum teams asking for more: the management of sprints and sprint backlogs. I played the game; and now all the agile teams at Kelkoo uses theSCRUM on daily basis.

Want to know more?

You can try the online demo to put your hands on theSCRUM, download theSCRUM, or read about the agile practices at Kelkoo.