Posted on Author Pallavi Godse Categories Blog

Agile Estimation and Planning – Planning Poker

Agile is not a process, it’s a philosophy or set of values to move quickly and easily. In this article I am going to discuss one of the effective agile planning and estimation method.

Planning Poker:

It is an Agile estimating technique which has become very popular in the last few years. Agile teams have taken advantage in using Planning poker cards as it is extremely simple to play and also powerful technique to extricate the collective wisdom of the team.

How to Play??

The basic rules are:

  • Each participant gets a deck of cards as shown in the fig 1.2 which represents a sequence of numbers or the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, etc.), which is more popular.
  • Product owner explains one User story from the Product Backlog to the team
  • Product owner answers all the relevant questions that the team have got about the User story.
  • Every participant selects a card which represents an estimate of the time, risk involved, complexity, and other relevant factors involved.
  • When everybody are ready with an estimate, all the cards are presented on a board for finalizing.
  • If there is a harmony /agreement on one particular number then the estimation is recorded and move to another User story.
  • Repeat the same process for all the User stories in the product Backlog as shown in the fig 1.3

Reasons behind the success of using Planning poker:

poker

  • Estimates are done in groups, logic behind is simple – Each person in the team have different experience and different ideas, there by benefit of teams collective intelligence.
  • Strengthen collaboration by engaging entire team.
  • Creates harmony in estimating rather than having a single person control the estimate.
  • Reveal issues early through timely discussions for each story.

Conclusion:

By following the correct process and making an estimate for each User story allows the team to understand clearly how much the team can deliver the working software at the end of each Sprint/iteration.

 

Hope you enjoyed reading…have a great day.

 

Sujatha Nalluri

Test Analyst

Adactin Group

Posted on Author Pallavi Godse Categories Blog

Agile Projects: How should Test Teams Adapt ?

When quality assurance teams and management who have adopted Agile practices first put the ideas to work, they face a significant impediment in unlearning the traditional mind-set and practices that experience in traditional practices has instilled in them.

The following adaptation practice was documented after our experience in couple of key projects that moved to Agile methodology. These practices are a real life saver for project teams that are new to Agile.

The following are some of the key aspects that need to be unlearned before attempting to deploy Agile practices, from a QA perspective:

 

  • The testing team needs to be independent and independently empowered in order to be effective.
  • Without a separate test strategy and test plan, it’s tough to manage testing.
  • The V-model for verification and validation cannot be applied in an Agile sprint.
  • Independent testing teams don’t do white-box testing.
  • The value of testing is realized only when defects are logged.
  • Automation is optional and is required only when regression testing is needed.
  • Testing nonfunctional aspects, such as performance of the system, is not possible in a sprint.
  • Testing must follow planning, specification, execution, and completion sequentially.
  • We don’t have to write new test cases for detected defects.
  • Poorly written code is not the testing team’s focus, as long as the code addresses the required functionality.
  • Test-process improvement models do not address aspects of Agile testing.
1 … 6 7 8