Get certified - Transform your world of work today

Close

A Guide to Implementing Scrum with AgileCraft

18 August 2016


The purpose of this guide is to help teams transition from Waterfall, or any other software development method, to Scrum, using test-management tool AgileCraft. It was not created solely to list the benefits of Agile/Scrum; it’s assumed that teams knew of the benefits when they decided to move to Scrum.

This article assumes some knowledge of AgileCraft. I will begin with story grooming, which is the first step toward achieving the goal of business value.
 

Story grooming

The story grooming meeting is held before the start of each sprint cycle. During this meeting, each feature and story, along with the associated business significance, is discussed with the whole team.

You can view the backlog in AgileCraft by clicking Team > Manage > Backlog. Then select the team name for those you want to see the backlog, as shown in the screenshot below.


 

Responsible person: Product owner/business analyst (BA)
 

Sprint planning

Sprint planning is held on the first day of sprint, during which quality assurance (QA) and development will timebox and estimate each groomed story in terms of story points.

The ScrumMaster must ensure that points for the planned stories will not exceed the capacity of the team. During planning, when story points equal the team capacity, no more stories are planned for the sprint.

Sprint planning can be done using Planning Poker® in AgileCraft by clicking Team > Manage > Other > Estimation Games.

Team Name is displayed on the day that the planning meeting has been scheduled; selecting the team name opens the Planning Poker screen, as shown in the screenshot below.


 

Responsible person: ScrumMaster, product owner, and team (development and QA).

Note: Before the sprint planning meeting, the ScrumMaster, product owner, and BA collaborate to write the acceptance criteria for the stories, which are groomed and scheduled for the sprint.
 

Task creation

After sprint planning, both QA and development perform the following activities:
  • Create detailed tasks for each story. Tasks are standardized in the first sprint, which can then be used as templates for subsequent sprints.
  • Complete task estimates with respect to story points provided during planning.
  • Review overall sprint capacity/allocation.
For the development team member, tasks can include:
  • Design changes
  • Coding
  • Unit and integration testing
  • Implementation
For the QA team member, tasks can include:
  • Test scenario creation
  • Test execution
You can create tasks in multiple ways in AgileCraft, by clicking Team > Manage > Team Room.

For each story, create tasks by clicking Add Tasks under Ranked backlog, as shown in the screenshot below.




Responsible person: Team (development and QA)
 

Team Allocation report

After tasks are created, the ScrumMaster must generate the report from AgileCraft and check that no team member is under or over allocated. Capacity must match the task loaded hours.

A report can be generated by navigating to Team > Manage > Assign Tasks, as shown in the screenshot below:




From here, the ScrumMaster can select the sprint. He or she can extract the team allocation as well as individual team member allocation information.

Responsible person: ScrumMaster
 

Story prioritization

Development and QA teams collaborate to decide which stories they want to focus on first. Create a rough delivery order of stories so that development can get the test plan/test cases for the stories before the unit or integration testing. QA can then plan execution activities accordingly.

Responsible person: Development and QA team
 

Gap analysis

If anything is found in requirements, QA must raise the these gap exposures and make sure that each acceptance criterion is testable and relevant to the story.
 

Daily stand-ups/Scrum

Stand-ups are held daily to track team progress. In AgileCraft, the option to run a daily stand-up is available from Team > Manage > Daily Standups. Selecting the sprint number opens the daily stand-up meeting window in which each team member's tasks are visible, as shown in the screenshot below, and hours can be burned against them.


 


For effective stand-ups, follow these guidelines:
  1. Which task was planned for yesterday, and whether you are able to complete the task as planned (approximately 45 seconds).
  2. What is the task that you are planning to perform today (Approximately 45 seconds).
  3. Any impediments or blocking issues that need to be discussed (approximately 45 seconds).
  4. Provide clear descriptions of user stories and of past or future tasks.
  5. Before the stand-up meeting, block the tasks if there is any impediment.
Conduct Scrum meetings in AgileCraft, and burn each associate hour against the tasks created during the meeting. View the burn-down charts in AgileCraft during the stand-up to check whether the team is on track.

Scrum discipline:
  • Every team member must join the daily stand-up on time.
  • Scrum calls should be short (no longer than 15 minutes).
  • No use of electronics during Scrum calls.
Responsible person: Team (development and QA) and ScrumMaster
 

Reviews of QA's test cases

QA incorporates the development team's review comments.

The following are criteria for a good test case:
  • Designed to find a variance in the system, not to prove that a function works.
  • Setup contains detailed dependencies.
  • If there are more than five or six steps in the setup, consider breaking the setup into more test cases.
  • Contains enough information to create a repeatable test.
  • Defines all test data values that would change the expected result.
The QA team must be able to identify and prioritize tests based on:
  • business requirements
  • functionality branching
  • technical requirements
  • importance to the business
On the test case sheet, define the priority as L1, L2, and L3:
  • L1: High-priority test case
  • L2: Medium-priority test case
  • L3: Low-priority test case
Upload test cases in AgileCraft, and share the links through email.
 

QA maintains test data

Test data is required for test case execution before the execution activity. Develop test data sheets separately, which are referenced by one or many test cases.

Maintenance involves two activities: Defining test data requirements and gathering and/or creating test data.
 

Story update on completion of development tasks

As soon as the development tasks are completed, in AgileCraft, change the status of stories from In Progressto dev complete.

Responsible person: Development team
 

Build deployment

Stories are deployed as soon as they are completed, and release notes are sent to the whole team, stating which stories have been checked in.

Responsible person: Development team
 

Defect tagging

During test execution, QA reports any anomaly, issue, deviation in expected behavior and logs the issue as a bug in AgileCraft.

When logging defects, following these guidelines:
  • If the defect is found against the acceptance criterion, tag it against Respective Story.
  • If the defect is found against the Smoke/Regression suite, tag it against Smoke/Regression.
  • If the defect is reproducible during User Acceptance Testing and was missed in the earlier QA story-test execution, tag it as a Historical defect.
Responsible person: QA team
 

Acceptance criterion validation

After testing is complete, change the status of all acceptance criteria of a story to Pass or Fail, and if it’s marked failed, log the corresponding bug in AgileCraft.

Responsible person: QA team
 

Story update on completion of QA tasks

If QA has tested all the acceptance criteria and no high priority/severity defect is in the open state for the respective story, change the status of the story to Test Complete.

Responsible person: QA team
 

Sprint review

The sprint review is held on the last day of the sprint cycle. The team shows a demo to business users and the product owner regarding the features that have been completed in the sprint.

For an effective sprint review, follow these guidelines:
  1. Before the sprint review meeting, share the order of the stories, such as the story and responsible team member who will be presenting.
  2. Before the meeting, fix the defects logged against the stories. Developers are responsible for fixing the defects related to the user story in the same sprint.
  3. Developers and testers must ensure that their stories are accepted during the sprint review meeting and the Definition of Done must be satisfied for all the user stories completed.
Responsible person: Team (development and QA), ScrumMaster, and product owner
 

Sprint retrospective

The sprint retrospective is held after the completion of the sprint cycle. In this meeting, all team members reflect on the past sprint and check three things: what went well during the sprint, what didn't, and what improvements could be made in the next sprint.

Responsible person: Team (development and QA), ScrumMaster
 

Maintenance of requirement traceability

To maintain requirements in AgileCraft, follow these steps:
  1. Upload test cases against the story/requirement. The cases are visible under that story (as shown in the screenshot below).
  2. Test cases can be executed in AgileCraft and can be marked as passed or failed based on the actual outcome.
  3. The acceptance criterion can be marked as Pass or Fail and, if marked Failed, the corresponding defect is logged and attached to the story.
This way we can track each requirement; for example, whether it has been tested and whether it has failed. The defect number against the requirement is shown.

The screenshot below shows that this story has 51 test cases executed, with four defects logged. Clicking the acceptance criterion shows which ones failed or passed.

Sprint closure activities

At the end of the sprint, update the regression package to include the current sprint stories' high- and medium-priority test scenarios. Upload the updated regression package to the QA repository in Confluence.

Responsible person: QA team
 

Scrum infrastructure requirements

Maintain a central repository or SharePoint for sharing the gaps, documents, and project artifacts and deliverables.
 

Best practices

Before starting with the test execution, QA verifies the following items:
  • Send unit test cases with results (Pass/Fail) to QA.
  • Automate the Smoke suite.
  • Run the automated Smoke suite to determine whether this build/release can be considered ready for story-test execution.
  • Complete the environment setup and data creation before story-test execution.

 

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: 3 (3 ratings)

Comments

Sourav Singla, CSP,CSM,CSPO, 8/18/2016 11:55:03 AM
One correction here with respect to grooming meeting

One of the majorly neglected meetings in Scrum framework is the product backlog grooming meeting and is a backbone for the Scrum success.
 Backlog grooming meeting should happen in every sprint and its primary objective is to prioritize and refined (or detailed) the user story/features that are planned for the upcoming/future sprints and ensure they meet the Definition of Ready (DOR) criteria or in other words they are ready for the development state. This greatly helps the team to go well prepared and confident for the Sprint planning meetings.
Sourav Singla, CSP,CSM,CSPO, 8/18/2016 11:56:19 AM
Also the Definition of Ready (DOR) should be met for each groomed User Story:
 Title
 Description – Any relevant details, specifications or sketches
 Small enough that can be fit in one sprint
 Concise acceptance criteria(s) listed – This helps to validate the intended business functionality for that specific story.
 List the dependencies (if any)
 How to demo it and whom to demo
 Estimate them in Story points
Tim Baffa, CSM, 8/18/2016 4:58:00 PM
Seeing as I am not a user of AgileCraft, there is no value to me in the tool or navigation discussion in this article. I would suspect that many other readers are also unfamiliar with AgileCraft, and likewise find no value with that article content.

That said, I can provide feedback on some of the Scrum-related statements:

- It is not the Scrum Master's responsibility to ensure that the team does not exceed their capacity in Sprint Planning. I am assuming that "capacity" is referring to velocity here, which raises the question of how actual changes in capacity are managed under this scenario (vacation, other meetings, etc).

The SM can certainly mention to the team when they have accepted close to their known velocity, but it should always be up to the team to accept an amount of work for the upcoming sprint that they feel comfortable with. The capacity/velocity metric is a “guideline”, never a hard and fast rule to “cut off” once reached!

- Why would you advocate estimating tasks in Story Points when you’ve already provided a relative story point estimate for the story? While there is value in defining the tasks for a story, estimating them by any means (story points, hours) is incredibly wasteful!

- As a Scrum Master, why would you be interested in assigning and tracking individual task allocation? What tells the Scrum Master what an individual’s capacity is, or whether they are over or under-allocated? Again, why does the Scrum Master care? Why isn’t the team allowed to self-manage at this point to complete sprint items without being micro-managed by the Scrum Master? Again, this is wasteful, and a very poor Scrum/Agile approach.

- Daily Stand-ups are NOT for status! They are an opportunity for the entire team to come together and touc base on the current sprint, where they are, what they have planned for the next day, and any issues they are experiencing. Also, tracking burn-down charts based on tasks can be VERY misleading. A team could be complete on 90% of their tasks, and yet not have a single “story” complete. A Burndown Chart should be viewed according to the team’s Definition of Done, at the story level. Done means done, and task completion is meaningless unless the story is complete.

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

Subscribe