Soft Skills 2nd Half Flashcards
Definition of Done (DoD)
The Definition of Done is an agreement between Development Team and the Product Owner on what needs to be completed for each user story, and it is often standardized across the company in order to guarantee consistent delivery of quality.
transparency of where you are and where your destination should be.
After all the testing has been completed
DONE = Releasable
Definition of Ready (DoR)
Simply stated, the Definition of Ready defines the criteria that a specific user story has to meet before being considered for estimation or inclusion in a sprint.
Requirements should be clear, understandable, and ready to be developed. I should be able to create test cases from the acceptance criteria
“Ready” stories should be clear, concise, and most importantly, actionable
Having a Definition of Ready means that stories must be immediately actionable.
Severity Levels - Blocker
This problem will block the progress
Ex: Customer is not able to log in with valid
credentials.
- Server is down
- The next page is blank
Severity Levels - Critical
A serious problem that could block progress. I am not blocked but the main functionality of the application is not working.
Ex: When transferring the money from one account to another, the amount is not correct on the recipient’s side.
Severity Levels - Major
The impact of the bug cannot be identified for the customer’s business
Ex. Not receiving the confirmation email or message.
Severity Levels - Minor
Trivial problem with little or no impact on progress.
Ex1: Look and feel of an application could be different from browser to browser.
Ex2: Alignment issue on the username and password.
Steps on Bug/Defect Life Cycle
New:When a new defect is logged and posted for the first time. It is assigned a status as NEW.
Assigned:Once the bug is posted by the tester, the tester assign it to the developer(s)
Opened: The developer starts analyzing and works on the defect fix
- Duplicate: If the defect is repeated twice or the defect corresponds to the same concept of the bug, the status is changed to “duplicate.”
- Rejected: If the developer feels the defect is not a genuine defect, then it changes the defect to “rejected.”
- Deferred: If the present bug is not of a prime priority and if it is expected to get fixed in the next release, then the status “Deferred” is assigned to such bugs
- Not a Bug: If it does not affect the functionality of the application then the status assigned to a bug is “Not a Bug”.
Fixed: When a developer makes a necessary code change and verifies the change, he or she can make bug status as “Fixed.”
Retested: Tester does the retesting of the code at this stage to check whether the defect is fixed by the developer or not and changes the status to “Re-test.”
Reopen: If the bug persists even after the developer has fixed the bug, the tester changes the status to “reopened”. Once again, the bug goes through the life cycle.
Validate: The tester re-tests the bug after it got fixed by the developer. If there is no bug detected in the software, then the bug is fixed, and the status assigned is “verified.”
Closed: If the bug is no longer exists then tester assigns the status “Closed.”
What is SMART?
SMART is anevaluation technique that can be used when writing software requirements.
S - Specific: Specific requirements say exactly what is needed, be clear (unambiguous), consistent in terminology, simple, and with an adequate detail level. Answering the questions: What?, Where?, How?, When?
M – Measurable: Break it down into measurable units
A – Achievable: Is your goal achievable?
R – Realistic: How much is relevant to you?
T – Timely: When do you achieve your goal?
Tips for the SMART Goal Setting
Small Action –> Big Changes
Get down to the Bottom
Once you have seen the bigger picture, you need to break the goal into simpler actions. This helps you understand how measurable and attainable your goal is. Planning smaller steps makes you build momentum in the right direction.
Use a systemized formula
We need to document our goals and steps.
Track your progress
We need to track our progress. So, we can prepare for our next step.
Set an End Date
The setting end date will motivate us to achieve our goal.
Definition of Ready (DoR)
CLEAR - TESTABLE - FEASIBLE
A “READY” backlog item needs to beclear, feasible and testable:
A user story isCLEAR if all Scrum team members have a shared understanding of what it means. Collaboratively writing user stories, and adding acceptance criteria to the high-priority ones facilitates clarity
An item isTESTABLE if there is an effective way to determine if the functionality works as expected. Acceptance criteria ensure that each story can be tested and meet the expectation
A user story isFEASIBLE if it can be completed in one sprint, according to the Definition of Done. If this is not achievable, it needs be broken down further
DoR - Sprint - DoD
definition of ready is the (ACTIONABLE) documentation before the Sprint and Definition of done is after the criteria and conditions have been accepted by the PO (RELEASABLE)
