Scrum||Boards are good for tracking a project’s:
- User Stories – self contained feature descriptions of the software being built
- Tasks –Server Deployments, Data migrations, Regression Testing
- Software Defects
Others terms for the above call them tickets, todo-items, issues, and bugs.
They are great in software industry for software development teams who are considering Scrum as their Software Development Life Cycle Methodology for the first time.
Great for Small teams that are collocated that do not need strict long term reporting or feature auditing. They are also good for teams that follow Agile development principles.
Scrum||Boards main customers will be those agile teams that are in the same office who can use Scrum||Boards alongside their existing project management tools or solo as the main project management tool ’.
From a whitepaper titled ‘Agile Tools’ authored by: Michael Dubakov and Peter Stevens. Before the conclusion there a section called: “When is whiteboard better than everything else” The authors objectively compared the simplest tools with the web-based tools for the collocated team and combined results in a small matrix. Below I have superimposed in blue text the area in the matrix best suited for physical Scrum||Boards from their results.
Scrumboards are good for people who want a more professional office place.
Self-made Scrum boards while practical and functional they do not look pretty. I have seen some made with Duct Tape also blue painters tape and various makeshift backlogs. While we have seen many engineering teams fill their own needs by making their own Scrum board the companies to which they belong may want a more professional aesthetic in their office.
Perform an internet search of ‘User Experience Hierarchy of needs’ you will see improvised boards meet the basic needs but do not bring the benefits of the higher needs of usability.
Using a Scrum||Board, outside of software development:
Companies in other industries that would benefit from using a ScrumBoards to represent the companies or teams goings on. Other industries might not do Daily Standups or perform software releases at the end of their iterations.
- Real estate companies tracking the steps of a home purchase .
- Construction companies scoping out work line items and tracking the progress of their project.
- Legal companies to define and track a set of tasks for their clients.
Scrum||Boarsd are good for companies whose work is ‘unique, tailored with finite tasks that although similar, are non repetitive tasks.’ and for many projects that have custom pieces of work that can be tracked over time and whose roadmap and respective work items can be re-assessed iteratively every couple of weeks.
Who might it not be good for?
Scrum||Boards probably will not benefit a team who is intentionally use another software methodology like the waterfall model.
Scrum||Boards are not good for remote teams unless the Scrum Master wants to keep a board locally for themselves.
Remote teams will not experience the full value of a standup meeting in front of the board that a collocated teams would experience.
It is important the members of a team gets re-confirmation of what they need to work on and if they cannot see those on a computer screen or their own ‘todo list’ then they are further removed from the tasks the need to complete.
Scrum||Boards are also not very good by themselves if the team is working on a project that need tracking of older user stories done in previous sprints/releases if no record of the userstory or work item is kept once the User Story/Task or Defect cards are dry erased.
Tight office space should be considered. Although the boards come with a whiteboard on the back and it’s always good for engineering teams to have whiteboards in the office, it is tricky to house a Scrum||Board when office space is limited. Scrum||Boards come in three different sizes and one cannot put the work of a full agile team’s iteration on the smaller Scrum Falcon model. A physical project management tool might not be the best choice in this case.
Other tools that make good Scrum artifacts
Many companies have developed Online Scrum tracking tools. Evolving from non contextual issue tracking management systems like Bugzilla now there are many issue management systems that model Scrum as part of their feature set.
Issue tracking systems that I have used that successfully model scrum include:
However there are many many out there and which one is right for your team depends on your needs.
Hybrid styles that work with Scrum||Boards
A team may get benefit from using more than one set of tools… for example using Scrumboards with Rallydev or JIRA, one can take the ticket/user story ID in rallydev and prepend the title in the scrumbord card with it. Using a Scrumboard with web based tracking software this way works really well.