How we do Scrum!

I’m writing this blog post to share my ideas and experience as tester within a Scrum team. This article will describe you how we define our way of doing things within the scrum frame work.

We need to be open minded and prepare for accept changes to start with scrum. So if you are a beginner to scrum, please be open minded even when you are reading this article.

Start of the sprint, first tasks for the testers should be creating test cases and corresponding test data/test files as soon as possible. And then store those information (test cases, test data/test files) in common location. What we do is we store that information in CVS.

Then testers should present their test cases to developers before complete the development tasks. And also testers should provide information about test files/test data with relevant to those test cases. Then developer could test their own codes against tester’s test cases and test files/test data. By this approach testers get more tested or more quality product to start their testing.This will be the first step towards Test Driven Development. Even though above mentioned approach is not clearly within the scope of TDD, we could adopt to that kind of approaches to drive the team to provide more quality product.

When tester found an issue then he/she should inform the relevant developer via immediate communication channel (verbally or via chat). After that tester writes a very short email to particular developer(s) with sufficient information to recreate or debug the found issue (This is not formal email. Only purpose of this email is providing sufficient information).

Normally we CC this mail to Scrum master and test lead as well. Test lead could a keep track of the issue if it’s necessary. Reporter should follow up the status of the issue with the developer until the issue gets fixed. What we do is we encourage our team members to do more and more pair programming, tester and developer together. This approach is work well for us towards provide quality code. If any of the issues not getting fixed and reporter still thinks issue is valid then, reporter could raise the issue in daily scrum meeting. We could store the bug tracking excel sheet in common location. Then reporter himself/herself can update the excel sheet and keep track of the issues by themselves. Current plan is to store this bug tracking excel sheet as a Google.doc or store in confluence. Then developers also could access the bug list and pick tasks directly from the list.

Purpose of this approach is reduce the waiting time of maintaining the cases in JIRA and increase the self-managed team efforts.

If developers have many issues to fix then, normally scrum master prioritized the issues with idea of the team. If the developers fail to fix all the reported bugs at the end of the sprint, then unresolved issues should report in JIRA at the end of the sprint. Then product owner could plan those JIRA cases to another sprint by considering the business impact of those issues.

After completion of a sprint we don’t need to keep the bug tracking sheet anymore, since at the end of the sprint either all the issues get fixed or rest of the issue are reported in JIRA. So we don’t need the excel sheet anymore.

If we found many blockers during sprint and if we see a risk of completing all the stories within the planned sprint then, best option is reduce the scope of the sprint, drop one or many planned stories. And move those dropped stories to another sprint. Everything we have completed during the sprint should be in deployable status at the end of the sprint, which means all the ‘done’ user stories should be ready for production at the end of the sprint.

We don’t change the sprint duration due to any reason. In scrum what we believe is we never negotiate about the quality of the product and we never change the duration of time boxed items. But we do have the flexibility of changing the scope of the sprint, due to major risks of completing planned to stories within the sprint.

During the sprint demo we present our test execution status. If there are any remaining issues we should present the particular JIRA cases which we have reported at the end of the sprint. During the sprint review (retrospective) we are discussing about our weak points, wrong turns during the past sprint and define new ways to overcome them within next sprint. And also we discuss about our good practices and ways which we can improve them on coming sprints.

I have used terms like test lead, developer and tester for explanation the process. But we have only three roles within scrum frame work, such as product owner, scrum master and team members.

This is my idea about how we do scrum.