Showing posts with label scrum. Show all posts
Showing posts with label scrum. Show all posts

Wednesday, 8 August 2012

Scrum in under 10 minutes - video

A great introduction to Scrum in under 10 minutes!  



For more information on scrum, visit www.scrum.org.

Sunday, 19 February 2012

scrum.org

Whilst looking for a course that would allow me to get some professional recognition for my scrum knowledge, I came across scrum.org. Scrum.org was founded c.2010 by Ken Schwaber, one of the original founders of the scum alliance. He resigned from the alliance in 2009 to pursue his belief that a transformation was required in the way the principles and fundamentals of scrum were delivered to users of scrum. There is more about that here.

Scrum.org offers a number of different training and assessment packages with several that are tailored towards developers, focusing on the core engineering practices that developers and scrum masters really need to understand to be successful in a scrum environment.

For more information on scrum visit:


and have a read of Henrik Kniberg’s Scrum and xp from the trenches:



Monday, 2 February 2009

Agile Test Strategy

[THIS POST HAS BEEN UPDATED: Please visit Agile Test strategy Updated!]

Over the years I have had to design really heavy weight test strategies to help sell/communicate to the business the reasons why we are testing and what we will do during each project. However, I have always found that no matter how good the intention set out in the test strategy is, what actually occurs during the test phase of a project is almost unidentifiable. Fortunately, on the last project I worked on I had the opportunity to develop a lean test strategy that was useful, practical, reusable, and above all, CMMi friendly!

Although not strictly a company that practised agile or lean development, we were trying to reduce the bureaucracy of traditional technical processes. The following is probably as light weight as a test strategy can get, but it works.

The idea was to make a statement of intention that loosely binds some of the more important test practices that can help a team move forward. The phases are fairly typical of agile development, although they do not represent a definite task execution flow.

Phase: Project Set Up
  • Understand the project
  • Collect information about the project
  • Create a test knowledge repository
Phase: Planning & Analysis or Release Planning
  • Assist in the definition and scope of stories
  • Develop test plans based on planning session
Phase: Development Iterations
  • Risk analysis during the sprint/iteration planning
  • Construct acceptance tests for each story
  • Develop business functionality validation plan
  • Document and write tests for defects
  • Automate with both unit and UI tests
  • Assist in functional review/demo
  • Accept User stories
Phase: Hardening Iterations
  • Regression test
  • Business acceptance testing
  • Develop release readiness plan
  • Run performance tests
Phase: Release
  • Assist in release readiness
  • Plan test release data and tests
  • Accept the Release
Using this basis for every project we can deliver software that has undergone rigorous testing but has not been delayed through the burden of traditional test documentation.

Friday, 30 January 2009

Agile Metrics

As a tester you will always find yourself absorbed in metrics creation, reporting on anything and everything that your management team wishes to report on. However, in agile development environments, sometimes its very difficult to assess the importance of metrics. I've been looking at some ways to provide management teams with interesting and useful information to measure our success.

One of the most fundamental approaches we can take towards metrics collection in an agile environment is the Return On Investment that a collection of metrics can give us. That is, how can our metrics help us provide more business value.

Using measurement goals such as only having 5 serious defects found in production after release give us more incentive to produce less buggy code.

Measuring the time it takes from the conception of a user story to seeing that user story providing business value also gives us an idea of how we are performing as a team. This is known as cycle time.

These metrics give us valuable information that provide us with the correct means to motivate a team.

Using the following principles, we can develop metrics that give us a decent ROI from our metrics:
Achieving SLA's relating to service and availability of products and systems.
  1. Low cycle time, that is, a high throughput of change.
  2. Low amount of unplanned work.
  3. Effective process improvement practices.
  4. Effective change management.
We can build metrics around these principles that give us usable metrics that bring value and motivation to a team.

Sunday, 2 November 2008

Agile Testing

I've just started work in a development team that has recently adopted scrum processes. Part of my initial tasks were centred around the implementation of a test process that works within scrum.

Here are a few links that will help you on your way to discover the delights of agile testing:
Even if you're not moving towards agile development practices, some of the techniques, tools, and practices referenced in the above links can greatly improve the productivity and reputation of the tester as valuable member of the development team. Take a look.