Generally, Support/Maintenance work involves lot of churn. Changes happen almost daily. Team has to work on high priority customer issues and sprint plan will keep getting interferences (unpredictable user stories) and tasks may need to be added in the middle of a Sprint. Maintenance project may not have releases as in the case of development projects. How do we handle this?

• Important thing to note here is to have a short Sprint. Generally 1 Week Sprint. This will make the Sprint Plan to focus on priority items that need to be worked, through out the week and to resolve issues. This will make customer happy.

• Keep more buffer time while planning the sprint – You never know if an escalated issue might land in your bin that may override all other current issues. If you have about 20% buffer time, you may be comfortably handle priority items without much impacting the sprint plan. If not new issues come, we just continue with the work and if there is bandwidth left, we may pick up more issues from the issues-pool.

• Scrum-ban technique is being adapted by many. It is a combination of Scrum and Kanban method. It mainly categorizes support tasks in to “Not started”, “In progress”, “Done” on a white board. Post its with task description will be used to categorize the current pool of tasks. For more do check this nice article.

An Information Refrigerator is a chart you have to open up and dig around in before you find the ketchup you’re looking for.

One of the best practice of Agile software development  is Information Radiator.

An information radiator displays information in a place where passersby can see it. With information radiators, the passersby don’t need to ask questions; the information simply hits them as they pass. Unlike Information Refrigerators, it takes very little energy to view the information.

An information radiator is a large display of critical team information that is continuously updated and located in a spot where the team can see it constantly. The term "information radiator" was introduced extensively with a solid theoretical framework in Agile Software Development by Alistair Cockburn

Information radiators are typically used to display the status of work, the condition of tests or load build status, the progress of the team. Team members are free to update the information radiator as and when the status changes. Some information radiators may have rules about how they are updated. Whiteboards, flip charts, poster boards or large monitor displays can all be used as the base media for an information radiator. In one of the projects where Agile Software Development is strongly practiced, we have seen large monitor which displays the unit test status, the load build status etc in a visible color codes fashion that is easy to digest.

Here is an example of a task board:

Source :  http://www.mountaingoatsoftware.com

Large parentage of organizations are believed to fail in Scrum due to the following reasons:

• Not implementing the whole process
• The team is not co-located
• Compromise on the Product Owner / Scrum Master roles
• Compromise on the size of the team

But how do you identify that the Scrum project is failing? There is no one single cause but a combination of problem areas that are dependent on each other like. Broadly the problem areas an be classified into:

• Emotion
• Culture
• Reflection
• Adaption
• Collaboration

In each of the above area, there are different symptoms that can indicate that the Scrum Project is failing. when you encounter such symptoms its easy to jump in and do a quick patch but it will not last longer if the root cause is not addressed. So, we have divided into two categories i.e Symptoms and Root cause under each problem area to help you clearly differentiate between symptom and root cause and fix the problem.

• Emotional
• Symptoms: Individual opposition, Confusion, Subversive Behavior, No Discipline, Apathy
• Root Cause: Fear, Influence, Preference, Superiority, Ignorance, Indifference, Position, Comfort
• Cultural
• Symptoms: Micromanagement, Mini-Waterfalls, Finger-Pointing, Revoking team discussions, detailed reporting, scrum master is seen as accountable for the team
• Root Cause: Heroism, command & control, bad values, limited accountability, hierarchical thinking, individual compensation, blaming, compliance
• Reflections
• Symptoms: Process at sprint n same as Sprint 1, no known Sprint velocity, no hands-on customer demo, no code reviews, stand-up monotonous, test and run before check-in
• Root Cause": Misleading metrics, no group reflections, missing self reflection, missing commitment, non-learning, wrong value definition, comfort zone
• Adaption
• Symptoms: Retrospective without actions, no time for change, do things that do not work again and again, no refactoring, sprint review without consequences, still no tests
• Root Cause: ineffective scrum master, cookie cutter process, imposed process, group pressure, invisible product owner, no empowerment, no adaption, too frequent changes.
• Collaboration
• Symptoms:Task handover, many loose ends, only business analyst talks to the customer, no team planning, not slowing down for teammates, deciding for customer, check-in race
• Root Cause: Segregation, hard-coded communication paths, push-systems, no shared responsibility, separation, turf wars and politics.

1. Always use a Software Revision Control – A code repository is a must to manage software development project. Revision Control software such as Subversion, CVS, Rational Clearcase etc are industry standard software that manage your software efficiently.

2. Automating the build – Single command should run the build – using tools such as Ant, Maven, MSBuild etc. This is very essential as it avoids manual build process/conflict/dependency issues and successful builds can even be emailed or SMSed to the concerned people. Build errors/stats could also be documented.

3. Every commit should trigger the automated build – This will ensure the integrity of each commit automatically.

4. Automated tests on built binaries/load (Self Test) – As soon as the build process completes, the sanity test cases are run – automated. Again, the test results can be broadcasted via email or SMS or via a Build Portal. This automation will avoid doing mundane tests on the build. This will give more time for the team to do more serious work.

5. Latest Builds Get Deployed automatically -  There is no other better way to please the customer to send the build or deploy the load automatically to their environment as soon as the build completes. We may decide to do this every end of sprint. Customer need to put any effort to get the new load.

Benefits are priceless but the main challenge is to build the CI environment and it requires some time and expertise. There are tools available for developers which could make life simpler.

List of CI Tools:

• CruiseControl – Java based framework to setup CI

• Apache Continuum – Continuous Integration Server and Build server

• Bamboo – Bamboo is used for continuous integration by over 1100 organisations in 53 countries around the globe

• Cascade – Faster, Smarter Software Development

• Rational Team Concert – Tool from Rational to improve build process.

Many tools are out there, please try and chose for your Scrum development work. Do let us know your feedback.

There are many commercial tools available. But, here is the list of free tools that are used for Agile/Scrum project management.

1. Agile Tracking Tool

Agile Tracking Tool is a free open source tool that helps in knowing how much work is in progress and blocked. It maintains your backlog items with categories and lets you add acceptance criteria and comments on the backlog item. It provides support to measure iteration velocity and forecasts when work will be done using the measured velocity.

More info here.

2. Kunagi

Kunagi offers integrated project management, supplementing Scrum by a selection of other best practices to cover all project management needs. It does not only offer management of basic Scrum documents, but also a variety of additional data.

More info here.

3. ScrumDo

ScrumDo’s focus on scrum fundamentals, simplicity, and ease of use make it truly unique.

More info here.

4. Express

Express is an open source, Agile project management tool. It provides tools for managing and tracking stories and tasks, projects and iterations.

More info here.

5. Scrumy

Scrumy is a project management tool based on Scrum.

More info here.

6. PangoScrum

PangoScrum is a free online tool for Scrum that lets you improve continually your efficiency while delivering. It provides a simple and friendly interface to write, estimate and rank priorities in your product backlog through. In PangoScrum the dates of your planning, review and retrospective meetings will be scheduled in a calendar for easy display and access.

More info here.

7. Scrumpy

Scrumpy is a free, standalone, 100% Java application specifically designed to help a Scrum Product Owner maintain a Backlog of User Stories.Scrumpy’s feature set has been carefully scoped to compliment your existing Scrum practices i.e. the ones involving a wall, sticky pieces of paper and people talking to each other. It assists with your day to day Backlog maintenance and provides you with a meaningful long term view that helps you to manage the expectation of your stakeholders.

More info here.

8. Agilito

Agilito is an open source, browser-based agile management tool that aims to do just enough for you to effectively and efficiently manage projects using an Agile methodology. It provides all that are required for Scrum project management.

More info here.

9. Banana Scrum

Banana Scrum is a web based, online tool for teams practicing agile development, primarily Scrum. It was developed as a result of Codesprinters team’s experience in creating high quality web applications . It is meant to replace project walls, index cards and other paraphernalia of the paper age long gone.

More info here.

10. Sprintometer

Sprintometer is a free and simple user friendly application with modern GUI for Agile projects’ management and tracking. It can be used for management of SCRUM and XP projects. To simplify data exchange with external programs all charts and spreadsheets in Sprintometer can be exported to Microsoft Excel.

More info here.

11. Agilo for Scrum

Agilo is a free and flexible, web-based tool to support the Scrum process. Agilo delivers streamlined functionalities for managing Scrum. It’s free and open source, and can be used without limitations.  It is highly configurable to adapt to your specific workflow. It is designed and developed for Teams, Scrum Master, Product Owner and for all Stakeholder who are involved in the project.

More info here.

12. Agilefant

Alilefant is a free and open source tool for project and iteration management.  Agilefant is capable of bringing together long-term product and release planning, portfolio management and daily work of the entire organization.

More info here.

iMeta Agility – Community Edition (Discontinued)

iMeta Agility is a Silverlight application for the management of Scrum projects. The iMeta Agility’s Community Edition gives you full access to the system for teams of up to 5 members for FREE. It provides every essential feature that is needed by Scrum like Online Multi User, Product Backlog, Story Management, Sprint Management, Task Board and Burndown Chart.

More info here.

IceScrum 2 (No more)

IceScrum 2 is a free and open source tool to manage a project using scrum. It lets you add stories to your product backlog, divide time in sprints and add stories from the backlog to a sprint. Users can pick up stories in the sprint backlog, estimate them, and complete them. You can also add tests on a story.

More info here.

1. Estimate the size of each Product Backlog Item by Planning Poker.

SIZE = Effort x Complexity x Uncertainty

Planning Poker to estimate the Product Backlog

• everyone reads the product backlog item
• Each person picks up the size estimate relative to the product item that has already been estimated. Normally this is the smallest estimate in the product
• Everyone shows the card at the same time
• if there is a significant variation in the estimates, then high and low are explained
• repeat the process up to 3 times until estimates stops to converge
• pick a number that everyone agrees to

2. Total the Product Backlog Estimation and you get the total of size. Say in our example, the total is 300 i.e full list = 300

3. Consider the teams velocity as 26 per sprint

4. Whole backlog would take 300/26 = 11.53 Sprints

5. Add Estimation buffer of 10 to 15% depending on your comfortless on the estimates. In our example we consider 15% Estimation buffer

15% Estimation Buffer = 15% of 11.53 = 1.73

6. Add rework buffer of 10% as you would expect to have some rework

10% Rework Buffer = 10% of 11.53 = 1.15

7. Add additional buffer of 10% to cover any risks

10% Additional Buffer = 10% of 11.53 = 1.15

8. Add 1 sprint as Pre-Release Sprint

9. Total Sprints needed for the project = 11.53 + 1.73 + 1.15 + 1.15 + 1 = 16.56 ~ 17 Sprints

10. You would need 17 Sprints for a Product Backlog of Size 300, and team operating at a velocity of 26 per sprint.

Hope these simple steps will guide you to estimate your project.

• Product Backlog is single list of things needed to be done as part of the project. These lists of things are User Stories or features in other words. These User Stories are prioritized as per customer’s needs and preference. User Stories at the top of the list are the ones badly needed by the customer.

• User stories could include functional and non functional requirements or any requirements that finally adds value to your customers. e.g. If you need a special automation testing tool to do thorough testing, then it could be a user story. This is because, better tested software always gives better product to customers and has great value for them.

• User Stories in the Product Backlog could generic and more the number of User Stories, the detailed is your Product Backlog. User Stories that would be worked first or high priority User Stories may be very detailed.

• Product Owner is the ultimate responsibility for Product Backlog.

• At any given point, however big the project is, there is only one Product Backlog list. During Sprint Planning, Team selects few User Stories (Sprint Backlog) from the Product Backlog based on the priority and starts working on them. This ensures that team always builds something that is of interest to the customers.

A sample Product Backlog:

Project is to build an E-Commerce Website that sells flowers.

• Sprint Review focuses on Product Review where as Sprint Retrospective is focused on the Process.

• Sprint Retrospective involves reviewing the way team works, interacts, behavioral aspects, improving technical skills so that the subsequent sprint is faster etc.

• How to conduct Sprint Retrospective meeting? – It is simple; Team along with Scrum Master asks 2 questions;

  • What went well

  • What could be improved?

• Sprint Retrospective is restricted to Scrum Team; i.e. Scrum Master, Team and Product Owner (optional).

• No one should be harsh on each other and should understand that it is only to improve the productivity.

• Outcome, if actions, removal of impediments, then Scrum Master has to make sure they are addressed.

• Sprint Review is attended by Product Owner, Scrum Master, Team, Stake Holders and everyone who is interested in the project. Larger audience is the key to get quality and unbiased comments/feedback. These suggestions and improvements are fed to the subsequent sprints. Product Owner should make most of the comments received during the Sprint Review. It helps him/her make the decision whether the team built/completed the committed features properly or not.

• Sprint Review involves the Product Demo (If needed).

• Product Owner reviews the product as per Definition of Done and he prevent the team from demonstrating the features that are not conforming to Definition of Done. Those features/User Stories go back to Product Backlog.

• Sprint Review often involves Product Owner with Stake Holders doing an in-depth review and provide the team an insight in to the market condition, value additions etc.