Get certified - Transform your world of work today


Agile-Scrum Best Practices

19 August 2015

Before I delve into Agile-Scrum best practices, let me outline the pitfalls we experienced with our own project in which Scrum was applied:
  • Requirements changed daily.
  • We had a fixed end date for product completion.
  • Although we delivered extensive functionality within a short period, the budget was not a constraint.
  • We worked with limited knowledge of Agile principles and practices, and the processes we followed were inadequate.
  • No automation tool was identified or procured.
  • Development, quality assurance, product, business analysts, and all teams were distributed across geographical locations and time zones.

Scrum project best practices

Not only did adopting the following best practices help us overcome those challenges and pitfalls, it led to the streamlining of our processes and increased efficiency. Here are the actions we now take:

Develop just the right amount of documentation.

This doesn't mean that you can avoid creating test cases, defect reports, or test plans. You should assess the correct documentation requirements (highly valuable) during your iteration or sprint.

Ensure that the quality assurance team is proactive.

Generally, quality assurance is considered a "bad cop" that interjects when people are doing things incorrectly. We try to work as mentors and establish a process that everyone can follow. We attempt to understand the application architecture and supporting technology that has enabled us to help the dev team resolve issues.

The team assumes responsibility for quality.

A peer review of critical deliverables and Agile projects is always important.

Ensure that the quality assurance team focuses on automation.

Web pages are automated as soon as the module is developed and submitted to the test team.

Increase the frequency of the quality assurance builds.

These builds help the quality assurance team test the user stories as soon as development completes them.

Create test cases that are easily maintained.

We create detailed scripts when requirements are changed during and after the iteration.

Understand every story well enough to test the functions and features that the client wants.

In one case we were able to test all functions properly, and we reported and tracked many issues. However, during our showcase, we found that the product didn't quite match the functionality and features that the client wanted.

Request and provide quicker feedback.

For teams that are distributed across various geographical locations and time zones, increase communication.

We overcame the challenge of collaborating with remote team members by:
  • Announcing every new issue discovered through Microsoft Lync chats.
  • Indicating which stories were affected by the issue.
  • Immediately sharing any blocker or critical issue.
  • Announcing when an issue was fixed.
  • Advising when an issue that was previously announced is invalid or duplicated.

All acceptance criteria should have at least one high-level scenario.

Every high-level scenario should have at least one test script. Share the high-level test scenario script with development and production teams. When everybody can anticipate what will be tested, they can make improvements to the unit testing and story content definition.

Conduct an effective retrospective Scrum meeting.

Retrospectives are an excellent place to start identifying what and how we can do better. We hold discussions about what went right, what went wrong, and how we can improve. So after every sprint cycle, we try to improve one thing that we failed at previously.

Rotate onshore and offshore resources.

Rotations are made at the manager, module lead, and developer levels. This improves the relationship between the onshore and offshore teams and brings fresh perspectives and learnings.

Focus on quality.

To improve quality, we implement the following techniques:
  • Continuous integration: One project had a continuous integration infrastructure that ensured that as soon as the code was committed, it was built, and JUnit tests were fired on the complete integrated code base. Any failures of builds or tests were communicated to team leads and developers who had checked in the last commit. The communication ensured that any breakages were identified and rectified almost instantaneously instead of waiting until the integration phase.
  • Automated testing: Automated testing supported continuous integration. For unit testing and integration within a module, we had JUnits with a code coverage of 85 percent.
  • Self-sufficient test data for unit testing: We used DbUnits to ensure that the test data that was required for the unit tests was loaded at the start of a test and then unloaded automatically. This ensured that the tests were independent of any data requirements from other teams or modules.

Apply quantitative measures of quality.

A number of quantitative measures were defined to ensure that quality was not measured subjectively. Applications for managing the quantitative measures included:
  • Clover for unit test code coverage
  • Checkstyle for adherence to coding and formatting styles
  • FindBugs for automated code review (this was augmented by manual Canoo Webtests)
  • Maven metric plugin to generate product quality metrics

Conduct an effective iteration planning meeting.

An iteration planning meeting is called at the beginning of each iteration to produce that iteration's plan for programming and testing tasks. The customer chooses the user stories from the release plan in the order of highest value to the customer. Failed previous stories or open defects are also selected. This selection is done using a Rally tool.

The customer selects user stories with estimates that total up to the project velocity from the last iteration. The use of an iteration planning tool helps track the product backlog and plan work by assigning the user stories per sprint.

Use effective management tools, such as Rally, for iteration planning.

Iteration planning tools provide the following advantages:
  • Identify user stories that are worked on each iteration.
  • Identify the point estimation for each user story, so you know which stories are more complex for both testing and development teams.
  • Quickly find out previous stories delivered and their respective iteration numbers.

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 2.3 (10 ratings)


Rohit Ratan Mani, CSP,CSM, 8/24/2015 4:14:12 AM
One of the toughest situation that I have faced is to have teams in different geographical location-multiple vendors-ignorance about Agile principles and making them speak-up about impediments in daily Scrum meeting. I had started with conference calls but was not able to get the result. I moved to having Video Conferencing for first month with all teams facing each other which made daily scrum more productive. Slowly i moved to conference calls and the team started speking-up.

Nice article Sourav.
Sourav Singla, CSP,CSM,CSPO, 9/6/2015 3:16:00 AM
Thanks Rohit
Sourav Singla, CSP,CSM,CSPO, 9/6/2015 3:16:48 AM
Thanks Rohit
Ashish Baviskar, CSM, 6/24/2016 6:57:47 AM
Nice descriptive article Sourav.

I would like to add two more thing:
Scrum hours should be burn daily to get proper burn down chart, which will help us to track the project progress and before time we can escalate any risk if found.
Any major changes during the sprint should be handle separately in next sprint otherwise we have to prioritize the existing sprint story to get things done.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up