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.
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
. Then select the team name for those you want to see the backlog, as shown in the screenshot below.
Product owner/business analyst (BA)
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
> Estimation Games
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.
ScrumMaster, product owner, and team (development and QA).
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.
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
- Unit and integration testing
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
> Team Room
For each story, create tasks by clicking Add Tasks
backlog, as shown in the screenshot below.
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
> 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.
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.
Development and QA team
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.
Stand-ups are held daily to track team progress. In AgileCraft, the option to run a daily stand-up is available from Team
> 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:
- Which task was planned for yesterday, and whether you are able to complete the task as planned (approximately 45 seconds).
- What is the task that you are planning to perform today (Approximately 45 seconds).
- Any impediments or blocking issues that need to be discussed (approximately 45 seconds).
- Provide clear descriptions of user stories and of past or future tasks.
- 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.
- 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.
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 Progress
to dev complete
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.
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.
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.
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
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:
- Before the sprint review meeting, share the order of the stories, such as the story and responsible team member who will be presenting.
- 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.
- 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.
Team (development and QA), ScrumMaster, and product owner
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.
Team (development and QA), ScrumMaster
Maintenance of requirement traceability
To maintain requirements in AgileCraft, follow these steps:
- Upload test cases against the story/requirement. The cases are visible under that story (as shown in the screenshot below).
- Test cases can be executed in AgileCraft and can be marked as passed or failed based on the actual outcome.
- 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.
Scrum infrastructure requirements
Maintain a central repository or SharePoint for sharing the gaps, documents, and project artifacts and deliverables.
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.