How to increase Product Quality through SMART Requirements
•Download as PPTX, PDF•
1 like•420 views
Support slides for my talk during the Agile Tour Vienna 2015. In the talk I covered basic principles of preventative Product Quality approach, importance of Acceptance Criteria and tips to increase their SMART-ness.
Recommended
More Related Content
Similar to How to increase Product Quality through SMART Requirements
Similar to How to increase Product Quality through SMART Requirements (20)
Recently uploaded
Recently uploaded (20)
How to increase Product Quality through SMART Requirements
- 1. How to increase Product Quality through SMART Requirements Matteo Taddei
- 2. 0 20 40 60 80 100 120 Requirements Design Development Testing Maintenance Relative Cost of Bug Fixing 100x 15x 6.5x 1 1x Source: IBM Systems Sciences Institute
- 3. It is better to try to keep a bad thing from happening than it is to fix the bad thing once it has happened. – Proverb
- 5. Lack of Flexibility Requirements Hard to Read and to Maintain High Risk of Overlooking Information
- 6. AGILITY The ability to change the direction of the body in an efficient and effective manner
- 7. Body of the Story & Acceptance Criteria
- 8. ACCEPTANCE CRITERIA Define the Testability of a User Story
- 9. Conditions that a Product Must Satisfy to be Accepted by a Customer or other stakeholder Ensure that the Entire Team shares a Common Understanding of what Should be Built
- 10. N O T H I N G
- 11. As an Italian user, I want to add a bank account to my e-wallet so that I can use it as payment method Acceptance criteria: 1. The selected country is defaulted to Italy 2. I should be able to toggle between "Enter IBAN entry" and "Bank account info". Default is set to "IBAN entry" 3. When I move the toggle to Bank account, the BBAN fields + Bank number entry field with help option would come up. 4. After I enter IBAN info, I see my Bank name automatically displayed 5. Newly added bank is successfully linked to my account
- 12. S P E C I F I C
- 13. The goal is Clear and Unambiguous There is No partial Acceptance: either a Criterion is met or it is Not Tips: - No Ambiguous language - No Subjective or Judgmental language (Better, Good, Allowable) - No Generalizations (All the time, Never, Everyone, Always)
- 14. M E A S U R A B L E
- 15. The Progress may be Quantified Determine when the work is Completed and outcomes are as Expected Tips: - Have a Set of statements each with a clear pass/fail result - Clearly define the boundaries and parameters of the User Story.
- 16. A C H I E V A B L E
- 17. Can be Realistically Accomplished given Existing Circumstances
- 18. R E L E V A N T
- 19. Must Have a Connection with the User Story
- 20. T I M E – B O U N D
- 21. Clearly State when the Outcome will be Observed Tips: - Avoid indeterminate amounts of time (soon, fast, later, immediately)
- 22. Acceptance criteria: 1. The selected country is defaulted to Italy 2. I should be able to toggle between "Enter IBAN entry" and "Bank account info". Default is set to "IBAN entry" 3. When I move the toggle to Bank account, the BBAN fields + Bank number entry field with help option would come up. 4. After I enter IBAN info, I see my Bank name automatically displayed 5. Newly added bank is successfully linked to my account
- 23. Acceptance criteria: 1. The selected country is defaulted to Italy, we have in the dropdown the other 28SEPA countries 2. I should be able to toggle between "Enter IBAN entry" and "Bank account info". Default is set to "IBAN entry” 3. When I move the toggle to Bank account, the BBAN fields + Bank number entry field with help option would come up. 4. After I enter IBAN info, I see my Bank name automatically displayed 5. Newly added bank is successfully linked to my account, marked as Confirmed within 3 days 6. I can link a Bank Accounts form any SEPA country to my IT account 7. I cannot Add the same Bank Account twice to the same account 1. We display the Account number in the following format: x-NNNN, where NNNN are the last 4 digits of the IBAN. 2. All letters in the IBAN field are displayed as Capital letters by default.
- 24. S p e c i f i c M e a s u r a b l e A c h i e v a b l e R e l e v a n t T i m e – B o u n d
Editor's Notes
- I’d like to start talking about product quality sharing with you this graph
- This is Source IBM, this is the cost of bug fixing in sdlc phases. I actually don’t know if the numbers we see here are correct or if the data are obsolete, for sure the trend is still good So when I see this graph, click
- immediately comes to my mind the old wise say prevention is better than cure, and it remember me the old commercial we had in italy when I was a kid, in the late 80s; whit a doctor promoting a toothpaste but saying, remember to brush your teeth at least 3 times per day because prevention is better than cure. So, how do we prevent defects?
- Easy! We need to do like these salmon; we need to go upstream, in our case upstream in the PDLC. How? Well, it depends how far we want to go but generally being involved in Requirement definition is one of the most efficient approaches. You can do it in several ways; static analysis, peer to peer review, walkthrough or other approaches. Now we understood why we need great requirements.
- Before talking to agile, I’d like to do a quick retrospective on waterfall; imagine that any drop is a requirement
- Now, in order to make understandable the difference between Agile and waterfall let’s watch this image and let’s think to what is Agility. I think we can apply it even in software: ability to change product development in efficient and effective manner. In order to have this flexibility in Agile requirements are smaller and independent and they are called user Stories. Let’s imagine the blue team as a set of requirements; all going to left, as expected; now we realized the requirement 24 had to go right. But only one; not the whole set of them!
- How do they look like? Like this – card! In one side you have the story description stating goal and benefit and on the other one you have the AC to confirm the story. Why are they important?
- To increase product quality, preventing these. How? Because AC Define the testability of the UST,
- State what’s written Now let’s see how they look like in the most of case, especially when you are not familiar with Agile
- What’s that? It is not an issue; it is click Improve this is easy; moving to nothing to something is not a big deal, let’s see an example
- Here we have a classic UST with % Criteria defined; as said we moved from nothing to something, but this is not enough! If I am a Dev and I look at that I got lost So, how can we improve? They need to be SMART; but what does it mean?
- Read tips
- Progress may be quantified State when a story is completed and working Read tips
- Let’s see now the AC we have seen earlier for the example story and let’s try to make them smarter
- Anyone want to try? We removed non relevat AC We added some more relevant one and smarter e added some word to make them smarter
- Anyone want to try? We removed non relevat AC We added some more relevant one and smarter e added some word to make them smarter
- Let’s have a recap Before leaving you let me show you some real number we achieved having this approach for one of our product