Saturday, September 19, 2009

Scrum and Documentation.(use cases/ test cases). ?


I know I was suppose to write few posts totally focused on practical aspects of user stories. But I thought to write this post first, because last week I had an interesting discussion at office which could be really useful to other agile practitioners as well.
We were talking further about agile testing. Especially with Scrum. We do have a separate well focused QA team managed by an experienced QA lead. In our model, the QA department is independent from any projects and they directly report to the Project Director. So how does this model work with SCRUM? I find sometimes its bit contradicting with concepts. We know Scrum has cross functional teams and each developer is responsible about their Quality. However, there can be testers too working in scrum team full time, they will be team members within the scrum team and coordinate with the scrum master. But if the QA department runs separately how do we do that? We had 2 options. Running 2 scrum teams for same project, you can call it scale up scrum, one for QA and one for Development, then have scrum of scrum everyday to synchronize with 2 teams. The 2nd option was for QA team to give permanent QA resources to each scrum team and they will apart from the QA department. In that case it would be an organizational change as well as we will be losing the concept of the power of an independent QA team who certify the delivery before delivering to the end customer.We thought of maintaining the same independent QA team and still to run Scrum ( if you don’t like me calling scrum for this method.. sure .. you can call it something different.:). ) But then the biggest problem is that how the QA team members get the knowledge of the product? Because, in a Scrum team the documentation is very less. We don’t create lengthy specifications and pass them over the wall. Then how does my independent QA team get this knowledge from the development team who participate the Product backlog planning meetings and sprint planning meetings.The following are the points we discussed;
1. One QA member of the QA dept participate the product backlog meetings as well as sprint planning meetings.
At the product backlog planning meeting, the assigned QA member with the team will decide which user stories will need use cases. Further, we discuss about using some very light weighted use case only when required. You can find a good article on some light weighted use cases for Scrum in http://breathingtech.com/2009/writing-use-cases-for-agile-scrum-projects/

2. Once the product backlog planning is over , the QA team member who participated the product backlog meeting will educate the QA dept head about the scope of work in QA dept with regard to the project.
3. In the sprint planning meeting, when the team decides of which vertical to be focused on, the team will create those use cases only for the specific selected vertical for the particular sprint. For that sprint, the sprint should have tasks and enough space to complete the use cases. In this case sometimes we may have to go away from our usual 2 weeks sprints to 4 weeks sprint.

4. Once the team finishes the required use cases, they will sign in to development tasks. The QA will have tasks to create the test cases during the sprint. So now we have test cases too.
5. Once the iteration is done (At the end of the sprint), the development team delver the shippable product increment to the QA department. , One of the tradeoffs is that this will delay the customers immediate delivery at the end of the iteration by few days.. But as a company, we need to assure the quality of what we deliver to the customer by our focused QA unit. I think this is better , so in this way, customers product quality is basically assured 2 times. Which enable us to deliver a very good quality product to the customer.

6. This QA dept quality checking also can be time boxed to few days as there cannot be such a bottleneck for the product owner to test the vertical.

I can see we can eliminate few practical problems in Scrum model by using few extra steps. Because we all may not have that “Luxury of right context” for scrum in real world business.

5 comments:

Mike said...

Great post! You indeed get in to real detail of practical side of SCRUM. We are never done with SCRUM. Every day we know that we need to make some adjustment to our process. One project is totally different to another. I appreciate all your writing and keep on writing please.
P.S. It’s better if you can organize the content in your blog in proper manner. You have great posts. They are very difficult to find inside the blog unless using keyword search. I suggest you improve on tags.

www.e-ict.persianblog.ir said...

i am very very happy that i see your weblog
im planner and i wanna that you add my weblog and i should add your weblog

thanks
www.e-ict.persianblog.ir

Thushara Wijewardena, PMP, Certified Scrum Master on 7:47 PM said...

Hey Mike,

Thanks a lot ! .. I understand what you say. the problem was , when I started this blog I never thought to go serious. never used proper tags.now that it has grown over 150 posts or so, very difficult for me to re arrange them. But Im trying to use a different template soon and will solve most the problems at once.. Keep on reading !!! :-)

Dennis Stevens on 7:17 PM said...

One idea would be to have QA write the Acceptance test(s) prior to release to the development team as part of grooming the backlog. This creates no additional work for QA since they are developing acceptance tests anyway - it just changes when it will be built. The acceptance test becomes self documenting and ensures QA has clearly communicated to development what is expected. You see some of this type of behavior modeled in Feature Injection. This will help greatly in flow when defects arise from a different understanding of the requirement.

Per Ola Sæther on 11:28 AM said...

Good post about Scrum and QA. I have been involved in projects that run QA separately and "out side" the Scrum process and also in projects with QA as a part of the scrum team.

In my opinion both ways are equally good because it depends so much on the project and what kind of organization you have.
Either way the most important is to be aware of QA and make sure that QA is a part of your project with dedicated resources.

Keep up the good work :)

 

PROJECTIZED. Copyright 2008 All Rights Reserved Revolution Two Church theme by Brian Gardner Converted into Blogger Template by Bloganol dot com