Scrum Alliance
The Scrum Alliance site is a very good resource for Scrum Articles, Scrum Training and finding out where Scrum gatherings are happening around the world.
If you have not checked it out yet, have a look. It may be of use to you.
Google Tech Talk. Agile Testing
Google Tech Talks
December 9, 2005
Elisabeth Hendrickson
ABSTRACT
As more teams are adopting Agile practices such as XP and Scrum, software testing teams are being asked to become “Agile” as well. But what does that mean? Is the Agile label yet another buzzword? Or could it be Agile practices are actually changing the way software is built? In this talk Elisabeth Hendrickson shares her perspective on how test teams can be more Agile based on her experiences working as a tester on Agile teams. Along the way, she’ll provide an overview of how Agile practices differ from traditional practices and discuss what those differences mean for independent test teams. Credits: Speaker:Elisabeth Hendrickson
Prioritizing :)
I have been on holiday from the world of Scrum for the past 3 days! It has been a welcome break from the hustle and Bustle from the Scrum Team! :)
Without knowing it, I basically used Scrum to plan out my holiday. As it was the first time I have been off this year, I had a list of things that I wanted to do with my time off. All of which wouldnt fit into 3 days. So therefore I put all of my tasks into a list and prioritized the list like a backlog and split the top priority activities out over 3 days (Sprint Backlog)
I managed to get all of my top priority interests completed and then I managed to pull in some activities that I thought I would not get round to.
There we have it, Scrum in Practice :)
Handling Bugs in an Agile Context
Handling Bugs in an Agile Context
This is an interesting article that was passed to me by a friend, thanks Mel! The article is based around the handling of Bugs in Agile Development. This has made me think about the way that my own team handle our Bugs. As QA and Scrum Master for my Scrum Team i am always on the look out to improve my skills in QA. Ill be taking some of the points contained in this article into account when performing QA on our team.
An important one is “Done means implemented, tested, integrated, explored, and ready to ship or deploy. Done doesn’t just mean coded, Done means finished, complete, ready, polished.” This doesn’t only mean that the software works, looks good and performs the way it should, the software should be fully QA’d and known bugs fixed.
How to fit QA into Scrum
I read an interesting article that addresses some of the problems that my own team has encountered with trying to fit QA into Scrum. We have found that on some occasions coding new functionality for our site can take up a large part of the sprint, which can have a knock on effect on the time that QA has in the sprint.
We know that this isnt exacly the scrum way of doing things as we should be testing early in the iteration and leaving the testing till late on in the iteration can seem like a waterfall practice, but sometimes needs must.
The article below explains a process that my Scrum team has carried out. We basically move our QA’ing of the stories into a separate story and have this prioritized in the next iteration thus allowing us to complete the QA without falling behind.
This also leads onto a future article on Automated testing in Scrum :)
How Scrum has improved our QA
I have worked at a web based startup company for the past 3 years. Before we implemented Scrum just under two years ago now, the QA team, of which I was a part of was a separate unit from all other teams. We worked with the watrerfall method of development which meant we were involved in testing our functionality late on in the project.
One problem with this was that if the project was over running, then our QA time was cut and we had to work hard to make up the time lost in development by staying late on occasion. This seems to be a common scenario with testing in the waterfall method. Another scenario that I found was that the team became stuck in a rut with testing. We became stuck in a routing of testing products in linear fashion that it felt as though every cycle was like groundhog day.
When we adopted Agile Development we had 4 main areas of expertise that were split into 4 main teams. The ratio was around 1-5 (QA-Dev / Flash) and QA is part of the Scrum development team. The Business side is driven by the Product team and our sprints are 2 weeks long. This was the start of something new for our QA department. Rather than being stuck at the end of the process, we were now included from the planning stage with Scrum.
We could now see the criteria being set down by the customer in the user stories that were provided to us by the Product Owner and any prototypes that were supplied. We now had an insight as to how the product should look and feel before the planning stage.
At first the planning stage was alien to us. We had not been involved in any planning before with the waterfall method. We had usually been given a product spec to write our test cases against before we were given the product to Test. Being part of the planning stage felt as though we were now part of the team, rather than something stuck onto the end of a project to make peoples lives a misery.
Taking part in the planning meetings allowed us to gain a more in depth insight into what the product being developed would be expected to do. Listening to both development sides to our teams plans on how they were going to code the functionality and how both Flash and .net would link together gave me an insight into any problems that may occur that could cause bugs in the code. I would then be able to ask how I could go about testing these areas and include this in my test case. This means that we are able to write our test cases earlier with the help of the User Stories and the developers.
Being part of the team during the development means that we are able to test earlier in the process. We have our own development environment which is updated regularly with new builds of the code base. Once these new builds have been installed we set about testing them and raising bugs. By testing against the criteria set down in the user stories and in our test cases earlier in the process, we can then find bugs early and have them fixed earlier thus meaning that we are not rushed off of our feet come the end of the iteration or the end of the project, had we been undertaking the waterfall method. With this in mind QA can help in the process of “defining DONE” for each Sprint which helps to keep the project on track.
Overall I have found an improvement in our working practives by implimenting Scrum. We have become part of a team rather than a seperate entity which helps us in our goal to try and have fully functioning software that is free of bugs. Being involved in testing earlier in the project has helped break the ground hog day effect as with the nature of Sprints, we could be testing more than one product at the same time, so this can break down the boredom factor of working on the same product for a long time. I have certainly found that our products have been going live with less bugs than before Scrum, so identifying these bugs earlier in the project has helped us.
Allan
The Mythical Product Owner Role
I was forwarded this article by a colleague. It basically describes the product owner role and categorises the different types of product owner. As a Product Owner could interpret their role differently depending on their ‘Day Job’ role it means that there can be different types of Product Owner depending on their role.
Take for instance, a product owner who works as a release manager, would be different to a product owner who works as a project manager.
It is an interesting read.
Twelve emerging best practices for adding User Experience work to Agile development
An interesting article on using agile to improve the users experience.
What is Scrum?
Scrum is a framework or rules that allows you to tailor your own lightweight process to develop new products. Scrum is simple, it can be understood and implemented in a few days, but it takes a lifetime to master.
“Scrum is not a methodology - its a pathway” Ken Schwaber
Scrum will also help you fail in less than 30 days. Unlike the waterfall method where the product is fully developed and then sent for testing. Scrum works in iterations of 30 days (or less if you have chosen short sprints). Each Scrum Iteration will aim to have potentially shippable code at the end of the iteration. This can then be tested and demonstrated to the customer. If the product developed does not work due to technical problems or it is not what the customer wants, then this will be found out within the 30 day iteration and can be subsequently dealt with. This is the opposite of the waterfall method, where it could be potentially a year down the line until you find out that your product does not work as expected or it is not to the customers needs.
Also, Scrum can also cater for the ever evolving needs of the customer. Code built using the waterfall method are often planned over a large timescale depending on the size of the product. It may be, that by the end of development the customers needs have changed and therefore the product being developed may be obsolete and may need further development to get re-tailor it to the customers needs. With Scrum, we can track changes and enter these into the backlog. By evaluating and adapting, we can better tailor the product to the customers needs sooner rather than later.
Effective Story Writing in Scrum.
A major part of the Scrum Process is Story writing. I decided to research the art of story writing so that I could improve my own story writing and hopefully improve the story writing capability of my team.
I discovered that all User Stories follow the same format.
As a <USER> I want <FUNCTION> so that <BUSINESS VALUE>
So as a Web based company, an example of a user story at my company could be: As a <NEW USER> I want to be able to <REGISTER> so that I can <USE THE WEBSITE>.
I then visited the Mountaingoat Software website for more information on story writing. I found that they use an acronym to help users write better user stories. I N V E S T. This stands for Independent, Negotiable, Valuable, Estimatable, Small and Testable.
Independent:
The story being written should not carry any dependencies. This could lead to estimating and prioritization problems. An independent story can ideally be worked on without the need to pull in any other stories in order to complete it.
Negotiable
Stories should have room for negotiation between the Team and the Product Owner. They are not a solid contract but some room for requirement change should be available.
Value
The story being written must have some value to the users or customers, not the developers. Stories should be written with the user or customer in mind. The story should define what a user can do and what benefit this would bring to them if the story is implemented. If there is no value to the customer or user, then the story should not be prioritized.
Estimatable
The Team should be able to estimate the amount of work that is needed to complete a story during estimation. If the team are unable to estimate the story, due to ambiguity, the stories requirements should be made clear. If the team are unable to estimate due to the size of the story, you will need to break the story down into smaller stories.
Small
Stories should be Small and relatively un-complex. Large stories by nature seem to be complex to manage and more often than not are 2 or more stories combined. Large stories should be split up into smaller stories in order to make them more manageable.
Testable
Stories should be in a testable against a predefined test case to verify that the story has been completed effectively.
Hopefully this will
