Should You Really Be Using Risk Poker in Agile?
What Is Risk Poker In Agile?
Risk Poker is an Agile method for risk based testing. Testing is a way of mitigating risk and in Agile Risk based Poker is a method to handle this.
Planning poker is a fun game based method that oversees user story points matched with related functional elements within an agile project.
Risk poker, on the other hand, is a risk based testing method, similar to planning poker, with the difference being, identifying key risks rather than estimation on user stories.
What is Risk based testing?
Software developers have it hard in their work. Their programs often undergo a lot of scrutiny before getting released into the market. Testing is a method used to identify product defects and software problems which are then returned to the developers. The criteria used in testing is solely based on the owner’s specifications.
Products are often at a risk of failing if they do not satisfy the consumers hence a product risk directly related to its failure. A risk based testing is an agile based approach that oversees tests conducted on a product based on the chances that it may not perform well on the market. This may be as a result of defects in its software coding or simply put as bugs or just shift and preferences in general consumerism.
Pressure from the market to deliver the finished product based on the fixed time frame as per the Iterations could also be another factor for product risk failures.
A risk based testing approach also determines the overall impact of failure and the importance of the consequences that may arise from the risk of failure.
What is Product Risk Management?
Different methodologies exist in identifying the gross mismatch between the market expectations and the finished product. Product Risk Management tops the list as one of the most effective way of managing the set of failures that may arise.
Proper analysis of the influencing factors that may result to the negative output of a product constitute risk management.
It is sometimes referred to as Risk mitigation because management tends to control the severity of the outcomes. Risk management is a lengthy process and often comprises of 6 steps.
- Identifying the two dimensions of risks: -by focusing on their strengths and weaknesses.
- Classification: -organizing and categorizing risks according to the criteria of your own choosing.
- Quantify: - you may need to use probability vectors to properly assess the veracity of the impact each risk poses.
- Plan: - this involves coming up with quick solutions to the already identified set of categorized risks.
- Implement: - you may need to put your idea solutions into good use at this stage and run them.
- Reiteration: - the need to repeat the analysis to make sure old risks remain buried and find out new ones.
What is a Product Risk Matrix?
After identifying the most crucial risks to be tested and quantifying them, rough estimates are drawn and numerical values assigned to their impacts.
A product risk matrix is a mathematical representation of the numerical values expressed divided into 4 different regions each representing a different level and type of risk involved.
Other mathematical based methods of graphical representation such as the use of Histograms and tabular like drawing of often complicated values aren’t as appealing as a risk matrix.
One advantage it holds over the rest is that it is very simple and easy to decipher. The horizontal axis can represent the impact of the risk while the vertical axis can represent the chances of occurrence of the risk involved.
As a result stakeholders may not need to rack their brains trying to figure out exact figures as seen in graphs.
What is the objective of Planning Poker?
Planning poker specifically aims at gathering feedback from all the team members on which way to deal with the project backlogs.
Planning poker also eases the overall estimation process by resizing an already existing story before its implemented. For overall success, you need to have self- control in order to determine when best to quit even if you are winning. Setting a limit becomes a bother especially if you are losing with the hopes of performing better.
In Scrum poker, how hard a story is doesn’t have a definitive method of determination. A dynamic process exists with non-definitive methods like vagueness in level of risks and uncertainty involved.
Contrast exists when defined values like countable figures specify planning poker. The most common poker method used is the Fibonacci sequence of numbers which each team member picks to represent a story value. Other examples include
What is Protection Poker?
The internet world is prone to security risks and unauthorized entry into organizations encrypted files. A method to counteract these illegal activities by malicious hackers is an agile based security risk game called Protection Poker.
The security based game is interactive, collaborative and comprises of a collection of ideas sharing past experiences that offer a better exposure for software security.
Brainstorming for solutions to patch up bugs and defective software coding as an overall risk is also included in the game experience. Team members are required to think like a software attacker and close up any breaches within the product’s network.
Final Words on Risk Poker
Quality service delivery is key in the final product, hence the reason we have the Agile Manifesto, for example. A substantial amount of funding should be set aside to assess and analyze the level of risks involved. It may not be possible to completely analyze every risk and test every aspect of a system as per the orders of the stakeholders.
Methods like Risk Poker, a light weight approach crucially takes care of this problem and gives you a more in depth analysis of the impacts of failures, should they arise. All in all, not infringing on your limited budget.
Before you go, lets look at some key Agile Sprint activities...
7 In Sprint Testing Activities You Need to Do to Get Paid
Introduction - The 7 In Sprint Activities
The mobile and web applications development sector has never seen a better platform than the Agile based methods of software development. If you are new to this technological advancement, here is an in-depth analysis of one the methods and terminologies used: Sprint testing.
A sprint goes hand in hand with Scrum as an agile approach to development which is extremely difficult to master. It’s a form of Iteration that involves quite a number of activities and if you aren’t careful to its approach, the overall structure may collapse. Here are what agile testers need to do in a sprint before the project can be termed as 'done’.
1. Test Estimation
Agile may have fully changed software development but testing software proves quite a challenge. The first step usually entails making a rough estimation for each user story created.
This involves a detailed time account for all the steps involved that provide an overall scope for the entire project. This may include:
- Identifying references to different user stories
- Analysis of the requirements of the story
- Sizing the whole story by giving proportional values depending on the amount of work to be done
A sprint is usually a development cycle. The scope of the estimate should cater for all challenges that may be encountered within the process. Many agile developers often complain about the possibility completing all the testing in one sprint especially if the sprint also includes backlogs from previous designs.
2. Design Test Cases
If you are a product owner, you would definitely employ the best team to meet your conditions and specifications. Test cases simply outline whether the system being tested meets the variables and requirements of the stakeholders.
A common misconception during the design of a test case is that a user story is a requirement. A test case is created manually with regards to the accepted criteria. Each and every product backlog goes into the sprint backlog where it is analyzed. This includes items like epics, features and user stories.
3. Work Closely with your team
Agile methodology is not to be confused with the traditional waterfall approach that run test checks at the final stages of the software development. Instead testing is done through each development stage.
This may increase product backlog as coding may be prone to bugs which may require technical support and knowledge acquisition.
High level descriptive functionalities are often specified under the user stories. Its complexity may prove quite challenging and its therefore important to grace the team with your presence to offer technical support and smoothen the whole process.
You may need to outline the user stories as the simplest increments that need to be built upon. Once the team understands this, you may need to reiterate the features which are usually too general to build. Using this knowledge, high level features need to be refined greatly to be done under a single sprint if possible.
4. Defect Management
Sprint testing often aims at ensuring the final program is devoid of any glitches and runs as smoothly as intended. This may be achieved through defect management which is the ultimate software debugging process.
Simply put, it’s a process that pin points to the exact bug and its location in a program and developing ways to fix it
Defect management involves four easy steps
- Detecting the source of the error
- Defect report writing
- Preparation of a defect list that includes all defects identified and fixed
5. Add Value in Stand-Up Meetings
Don’t always be the member of the team who is always absent in important group gatherings. It is important to always show up punctual to daily stand-up meetings to review the overall progress report.
In Agile, silence Is never golden. Share your thought and ideas on how to tackle the most troublesome processes encountered. Your focus should be purely on ways to complete backlogs and new challenging projects.
For instance, do not focus on what you have already achieved or what you are intending to achieve as this will come off as a bit of a show off. Instead, psych up the team and provide solutions to general problems they may encounter.
6. Have a clear exit criteria
Even before you start testing, it is important to have a clear, and agreed exit criteria. The "agreed" part is probably the most important. This means you know when you can exit the process, without going round in circles, continuously raising defects, and re-testing.
An example may be, maximum of five sev 3 defects open, after test completion.
7. Work Closely with Stakeholders
One of Agile’s tenets is its dynamic ability to welcome change. You may need to learn a few details of the task at hand through working closely with the responsible authoritative figureheads.
These may include additional funding in cases of limited resources. Coming from a traditional based developer methodology, you may need to learn about the agile based software. There isn’t anyone more knowledgeable regarding your line of work as the stakeholders.
Conclusion - In Sprint Activities
As an agile tester, negative afterthoughts like the sprint being too short should be discouraged. Planning and collaborative effort is usually key to these kinds of problems.
Trying to mitigate problems during a sprint test is usually a bad idea as the problem will keep on recurring. To ensure you reap the benefits of your work, you may need to simply create test automations that will check on regression and performance during each sprint.