As Scrum and other Agile practices gain wider adoption there has been more need for tools to help manage these types of projects. Yes, I know, the Agile Manifesto says to respect “Individuals and Interactions” over “Process and Tools”, but even the purists are seeing that larger scale projects require something more than the prescribed low tech task boards and sticky notes. If used correctly these types of tools can help with your Agile practices.I constantly see postings on various Agile forums asking what is the best tool to use. There are even several blog posts out there outlining the pros and cons for the various packages currently on the market. I find the choice of which tool to use is very contextual and while you do need to do you research on all the different vendors and offerings, you should really get a good idea of what you want from a tool before you go out looking for one.
For instance: If you are a smaller shop that has been previously using the note card and sticky note approach, you would probably not want to jump into a larger, all encompassing tool at first. A larger shop that is moving from a much more structured approach would tend to want something with more features to give them some of the same abilities they had with their previous toolset. Also, various people (Product Owners, Scrum Masters, developers, testers, stakeholders, etc.) have different expectations of how they will interact with these tools and what they will get out of them.
So I thought I would talk about what functions you would perform in these tools and what to look for while evaluating them:
Product Backlog Maintenance
Argue with me all you want, but managing the Product Backlog is one of the more important jobs in Scrum. If you have a crappy Product Backlog, you will get a crappy product no matter how well the actual practices in the Sprint are performed. So what should we look for in this area?
- User Story Support: User stories are basically the standard way to capture requirements in the Agile world and any tool claiming to be a Agile management tool should allow us to easily record and manage them. This means containing areas for the user story, conditions of acceptance (or How To Demo), acceptance tests, story points, business value, and delivery order at a minimum.
- Other Product Backlog Types: While I just stated that User Stories are the primary mechanism for capturing requirements, I do think there should be support for capturing things like technical requirements in the Product Backlog too. Even if I record these non-functional requirements in the same User Story format, I like to have a way to define it as a technical requirement for reporting purposes. It also helps with testing since these types of requirements sometimes do not change the user interaction so there would be no new user acceptance tests, but they often require extensive regression testing of existing functionality. Having a way to separate these types of requirements is helpful to the testers to know what will require new tests to be written.
- Batch Entry/Editing: From experience I know that a tool that requires me to open various windows to enter or edit multiple Product Backlog items makes planning meets a laborious process. The best support I have seen for this functionality is the ability to export and import from Excel.
- Epic/Theme/Feature Hierarchy Support: When planning a large scale project it is important to see the smaller user stories in their larger context by grouping them as feature sets, which relate to a theme, which originates from an Epic. I’ve heard complaints from management about Product Backlogs with small User Stories are tactical approaches and they want to see things at a strategic level. By rolling the smaller stories up to these various levels you provide that type of view to them.
Sprint Backlog Maintenance
Transparency is a key element of Scrum and keeping up with the tasks in the Sprint Backlog accurately is one of the keys to providing that visibility. While the Product Backlog is managed by a single person normally (the Product Owner) and is not usually touched every day, the Sprint Backlog is managed by the entire Scrum team and should be updated daily (if not several times a day). This makes the nuances to interacting with the Sprint Backlog a little different. Here’s what I look for:
- Easy Access to ‘My’ Tasks: Since we want the team to update their tasks frequently, I need to make it as easy as possible for them to view their open tasks, update the task, and grab another unassigned task. While Virtual Tasks Boards are great for this in the Daily Scrum, I just want to talk about editing the Sprint Backlog items during the rest of the day. The best way to ensure this is to integrate with the tool I use most often, which for a .NET developer like me is Visual Studio. But we cannot forget other team members like testers who may or may not being using the same tool.
- Batch Entry/Editing: Once again from experience, when you are adding multiple Sprint Backlog items in a Sprint Planning meeting, having to do it one at a time in a new window for each one is a time suck. Excel is once again a great way to do this so look for export and import from the Sprint Backlog as well as the Product Backlog.
- Custom Views: As a Scrum Master you will frequently be looking at the Sprint Backlog for various reasons. Because of this you may want to sort or filter the view differently. Having the ability to create your own views of the Sprint Backlog (and this goes for the Product Backlog too) is essential. For example I use a view that shows me what Sprint Backlog tasks were edited today, yesterday, and three days ago (for Mondays to see what was edited on Friday). Scrum team members can also use this for the ‘My tasks’ functionality I mentioned above.
- Product Backlog Linking: Just as a User Story links back to a feature, theme, and/or epic, each Sprint Backlog item should link back to an item in the Product Backlog. This is essential for reporting purposes. On the opposite side of that rule there will be unplanned work that may not tie back to the Product Backlog and I should be able to easily identify these orphaned tasks.
Information Radiators
Alistair Cockburn coined the term ‘Information Radiator’ which he described as a type of display that relays critical and frequently updated project information. Furthermore the display must relay the information in a way that the viewer requires very little effort to gauge its intent. In other words I should be able to walk by and with a glance get an idea of the status of some facet of the project. These are normally displayed in the open where the entire team can see them, but with distributed teams that becomes difficult. Here are some of the features and specific types of Information Radiators to look for:
Types of Information Radiators
- Sprint Burndown Chart: The most useful and common of the Information Radiators is a must have in any tool. Some additional features I have seen in some tools that I liked:
Track Done Burndown: Most burndowns are based on “work hours remaining” which sometimes does not tell the whole story. If you have only 20 hours left across 4 Product Backlog items then it would look like you are doing well, but if there are 5 hours remaining on each Product Backlog item and none of them are done then it can be misleading. A track done report simply reports on the number of Product Backlog items that have been marked as Done versus those Not Done (and sometime it will show In Progress ones differently).
Capacity Trend Line: This is the line that shows you where you will be based on your team’s current capacity based on the number of hours to be worked. It is a good indicator if you have bitten off more than you can chew from the start.
Moving Average Trend Line: This one always threw me for a loop until I understood what it was supposed to show. There a several flavors of this (the most complicated being Linear Regression), but what it boils down to is based the average rate of burndown (positive or negative) from a set portion of history, if you continue at that rate the line shows you where you will be at the end of the Sprint. So if you are entering more Sprint Backlog hours at the beginning of the Sprint than you are burning, this line will slope up because if you kept adding more hours than you took away you would never reach 0 hours. It usually looks this was at the beginning but when we really get cooking and have stopped adding in new tasks, the trend line tips over and we get an idea based on an average of our last few days where we would wind up if we kept that average up. If that does not make sense then read this, which will probably make even less sense! - Product Backlog Burndown Chart: If you have multiple projects each with their own Product Backlog, then the Product Backlog Burndown is a good indicator of how close you are to finishing the entire project. It shows the number of Product Backlog items remaining either over time or by Sprint. If you have a companywide Product Backlog then this has less immediate relevance since if it ever went to 0 then you either reached perfection or went out of business!
- Hours/Tasks Breakdown by Team Member: There are several versions of these types of reports but they basically show each team member and how many Sprint Backlog items (or tasks) they have closed, are currently working on, and the hours remaining. It is a quick snap shot to see if someone is falling behind. This should be something you naturally discover during the Daily Scrum if you are doing it right but with larger teams it may not be as obvious.
- Bug/Fix Trends: Management loves metrics about bugs: How many bugs did we fix last sprint? How fast are we fixing bugs? What is the breakdown of bugs by testing/user impact? Having some nice graphs and pie charts to show the answers to these questions in an easy to view display makes management happy. It can also help a team quickly identify if they have a code quality issue.
Display Options for Information Radiators
As I said before, it is important that Information Radiators be as visible as possible to the entire team. So there are other factors to consider from a tool in this area:
- Multiple Means of Access: If the tool only allows you to look at these charts and reports through the tool itself, then you will have limited options when trying to display them for your entire team to see or offer management a way to view them on demand. Most tools provide these reports via the web which can work for most situations, but the better tools I have seen offer them through something like SQL Reporting Services which has many options of delivery including web, email, and exports to Word/PFD/Excel. This will be especially crucial for a distributed team to all have access to this information.
- Rotating Views: Frequently I see companies putting large LCD screens in various places around their buildings to convey information to their employees. This is a great idea for information radiators also. A good tool will allow me to pick and choose different reports to be displayed on a rotating basis on an external monitor making it a very effect way to show everyone the status of our projects.
One of the reasons the Agile world tends to stay away from management tools is that they may force us to adopt the tools process over the process that is best for our team. So for a Scrum management tool to be effective, it must allow us to customize it to fit our needs. Here are some common customizations:
- Ability to Edit Backlog Fields: There have been many times when implementing Scrum for a client that they have needed to record additional information in the Product and Sprint backlogs. This would require the management tool to allow us to add, edit, and remove fields for backlog items.
- Ability to Edit Backlog Workflow: We are used to the standard ‘Not Done’, ‘In Progress’, and ‘Done’ type workflows for Product and Sprint Backlogs, but often teams will want to modify these for things like ‘Ready For Test’, ‘Deferred’, ‘Code Reviewed’, etc. Not only is it nice to be able to change the states, but changing the workflow rules is a nice feature along with it.
- Ad Hoc Reporting: When you start using a management tool in the Scrum, a ton of data can be captured. You start to be able to easily track trends like how fast does the team close and ‘In Progress’ task, how often do we add new tasks in the middle of the Sprint, etc. This is very useful information and the ability to pull that data out of the tool and report on it can give your team much more insight in how it is performing.
Integration
Managing backlogs is only one part of the Scrum process. During the Sprint there are tons of activities going on that may use other tools such as unit testing, source control, feature testing, automated builds, etc. The ability to integrate with these tools can add even more power to your management tool in a few ways:
- Linking Source Code to Backlog Items: When you add code to your source control repository, the ability to link it to the appropriate Sprint Backlog task (and through that the corresponding Product Backlog item) gives you even more reporting options. You can quantify the exact codes changes that took place for any given requirement.
- Automated Work Item Creation: A common example of this is creating a Sprint Backlog task to after a broken build. If you have setup a continuous integration tool that builds whenever code is checked in or on a scheduled basis, if that build breaks you can have a Sprint Backlog task automatically created to fix the build. You may already have internal software tools for tracking bugs or high level requirements and having the ability to setup some type of synchronization between those tools and your Scrum management tool can help with adoption since it builds upon tools your company has a current investment in.
- Linking Test to Backlog Items: Just as with source code, the ability to link unit tests or automated feature tests to Sprint/Product Backlog items helps with stuff like traceability matrices. If management asks the impact of changing a piece of functionality you can easily make the change locally and then run all the linked tests to see what it breaks or ensure it does not break anything. It will also help identify tests to be run for regression testing when changes are made to existing code.
Making the Choice
The functionality above covers the biggest feature sets I can think of, but there are probably others. While most of the mainstream tools out there cover the basics fairly well, the other functionality mentioned above could be the deciding factor over one or the other.
My advice is to think of what is the most important set of features for you team and then examine each of your choices to see which ones fit your criteria the best. To help get you started below are some links to some of the top tools on the market. Happy hunting!
20 comments:
You left out Pivotal Tracker. It's a great tool, and though it's still missing epics (they are on pivotal's backlog) It does most of the other stuff you want. In particular, it is actually easy to move stuff, start and stop and even edit stories w/o opening a new window.
Check it out http://pivotaltracker.com/
Agilebuddy is another tool that one should/can, consider.
Good blog. I have used version one. Its a good tool with web2.0 features. But it requires some amount of training initially as the tool has got tonnes and tonnes of features. But my favourite is still the "Excel Sheet" :)
Nice blog.
For someone starting the process of assessing tools available on the market try:
http://www.userstories.com/products
If only I had time to really take a look at all these great products.
Clive: Thanks for that link. That is a great list of tools. Which one do you personally use and why?
Whenever I advise Scrum teams on tooling, I tell them to take the following steps:
1. Make sure your team knows enough about Scrum to practice it.
2. Practice it, get some Scrum "muscle memory," and get comfortable with Scrum in your real world using the low-tech tools typically taught in CSM classes (white boards, sticky notes, etc).
3. Let your team try any tool you're considering for at least a couple of sprints. Don't buy a tool based on a procurement check-list alone.
4. Pick the tool your teams will actually use. There is nothing sadder than making a huge investment in a tool just to find out that your teams hate it and won't use it.
Finally, don't think you will learn Scrum from a tool. Scrum is a set of practices, principles and values. Get those down first and pick your tool based on the needs you discover as you implement Scrum in your real-life organization. Tools are great but they're not a substitute for quality process.
In the spirit of transparency, I work for Danube but I think this is a good product-selection philosophy regardless of what class of products you're considering. You wouldn't buy shoes without trying them on, would you?
Actually, I agree with Katie, but I would go farther. There are some reasons to replace cards with an electronic tool, but they are far fewer than you'd think. Maybe your team isn't co-located? Other than that...
In most other situations, I'd vote for a wall of cards that everyone gathers around during the scrum and talks to.
You could of course ALSO have an electronic tool. Maybe the electronic tool if for managing the backlog, while the cards are for managing the stories in play this sprint.
I do find that there is something you lose the minute you step away from a physical medium like cards that hundreds of thousands of dollars in tooling doesn't give you back.
Dynamicism & empowerment - You can completely change the structure of the card wall if the team decides something else would work better - probably in less than five minutes.
Information radiation - You can set up your wall to show whatever information you find to be important. Do so and you won't need those LCD monitors.
Developer pride - Of course, as a developer, there's something immensely satisfying about going up in front of everyone and moving a card to "done"...
Of course, most people convince themselves all of this isn't _so_ important and that you get more than you lose from a tracking tool. If you see yourself going in this direction, make sure it's true! And like Katie says, no harm in trying something and then having the team decide which way to go based on empirical evidence.
Tommy,
In answer to your questions. I have used both RallyDev and VersionOne in the past. In my view both are good products, but I always found them lacking in certain areas. Usability is always an issue, especially as the provider has to create their interpretation of Scrum/Agile processes and implement that vision in their product. Therefore you have to understand the provider’s interpretation before getting to work with the tool.
The other extreme is that the provider creates a highly configurable product. The downside is the effort involved in configuring the tool to your interpretation of processes.
The main reasons for me to use a tool rather than index cards/sticky notes are:
1. Distributed teams
2. Scalability (managing a backlog of 100 epics/stories in a challenge on stickies!)
Recently I did a review of many of the tools on the market to determine if a product existed that would overcome some issues we had with our current tool. As a result we have built our own tool. In the near future we intend to release it to the market. If you would like to be involved in the closed beta of the product let me know or register here:
Thank you for posting the link to ScrumDesk.
Best Regards,
Dusan Kocurek
ScrumDesk Product Manager
Most of the companies I work with on adopting Scrum are larger and need some type of management tool. Using a digital task board that ties back to these types of tools allows for better reporting on history which is harder to do with the notecard/sticky note approach.
I agree that nothing provides the tactile nature of note cards, but we use Conchango's Task Board which connects to Team System and have gotten great results. I am building a setup like the one in this link (http://www.youtube.com/watch?v=QFn60RhlcG4) to try out and see if we can get some of that tactile nature back.
.. and to join the queue of the left-outs - Norman, can you add www.targetprocess.com to your? As I read your blog post, TargetProcess fits if not completely, but to a very large extent to all those characteristics of the ideal agile tool that you've covered.
ScrumNinja is another up-and-coming scrum tool. It's great for small teams and a lot of people enjoy it's simplicity. The features are still being solidified via customer feedback, and we will definitely take your ideas into consideration. Thanks for this post!
I will echo what some others here have said. don't START with a tool.
There are many teams out there that are STILL using notecards because they don't NEED whatever 'additional' stuff a tool adds. I've looked at a number of tools and really yet to find one for example that can:
a) minic the level of 'big picture' you get from wall of cards.. letting you really 'see' nearly everything in a sprint at once.
b) make it as easy to order and rank items in the backlog as it is sorting through a bunch of cards on a conference table or stickies on a wall.
it's not just tactile, its things like visability and ease of use. notecards and stickies my seem like only a half step from cavepaintings in terms of the tech level, but there's simplicy, visability, and ease of use that's harder to acheive in a tool limited to a 24" (or typically smaller) screen.
tools can have a lot of neat features, but if you team doesn't need those features are they adding value, or more work?
learn scrum first, figure out what you need that cavemen tech doesn't get you, and then rank those needs just as if you were ranking features in a product you were going to build. THEN go looking for a tool that meets the most important needs the best.
I'm in the place Jeremy described. I have a wall full of cards for my sprint task board and a page from a flip chart for my burndown. I like that and changing to a tool for sprint management would only hurt what we're trying to accomplish.
It's on the product backlog side that I feel I need some help. Excel got me to a certain point, but I have lots of BAs contributing backlog and folks at other sites that would be interested in seeing our development priorities. Excel's ease-of-use plus better multi-user support, reports/graphs (that won't break when someone cuts and pastes in the wrong part of the spreadsheet), on-line visibility, control of who can edit priorities and estimates, and light-weight integration with TFS would get me where I want to be.
Of course, I'm biased, but I wanted to say that ScrumWorks Pro is incredibly easy to use. We make it especially easy on developers with our web client, which is essentially a virtual version of the Scrummiest tool around:a task board. (SWP has a desktop client, too, but it's for more complex functions than updating tasks.) You can take a look here: http://www.danube.com/sw_flash/quick_start_demo/quick_start_demo.html
What about ScrumEdge? I've been using it for 2 sprints and i love it! I like that it doesn't take much time to set up my projects, backlog and sprints and the charts (burndown, budget and burn rate) are awesome.
I wanted to add that often teams/organizations which are new to Scrum try to fix symptoms by using a 'tool' - e.g. the Scrum Master does not have the time to update the burndown chart manually. Instead of fixing the real problem, they 'just' add a tool.
However, for some teams a tool can be nice add-on as several commenters already mentioned.
Probably you should also add Agilo for Scrum to your list of Scrum Tools (www.agile42.com). ScrumWorks Pro did not please me particularly - may it was just an old version but I didn't see even an ideal burndown (let alone capacity).
However, the team should always decide what tool to use.
Thanks for a great post!
I'd rather opt for a tool as close to my team needs as it's possible rather than a big all-in-one tool with tones of buttons and loads of configuration to do.
Isn't that better to keep it simpler and adjust your team a bit to some constraints imposed by the tool? what's your opinion?
An excellent article and some real insight being offered in these comments.
Bright Green Projects have recently built an Agile Project Management Tool and launched it successfully after an intense beta testing phase.
I would like to echo some of the other comments that a tool alone will not solve your problems. You need to understand the methodology you are trying to follow and then find an appropriate tool to help you follow it.
Maybe a simple tool such as stickies on a wall going to be enough, or is a more scalable and globally accessible solution a better option?
Requirements and Test Management Repository". This is a test tool software which allows to manage software requirements and describe the scenarios and associated test cases and run them through targeted campaigns. In addition, it provides precise Bug Management Tools of software evolution through a versioning system for projects, requirement and test case.
Post a Comment