Thank you Sunand, I have watched all ur videos and taken notes out of it. Thanks to all ur videos i got 2 offer letters for the scrum master role. Thank you once again Sunand!!
My thoughts on estimation 1. Estimating the hours - need to very specific. So in terms on hours we wouldn’t be a good position whenever there is complexity or unknown. Also, if we estimate in hours we will have to deliver in that given time. 2. Estimation using story points: again we can use Fibonacci series or 3 point estimation etc. the whole purpose of this is considering the effort, complexity and the unknowns. More like the grade system that we have in school. The reason Fibonacci series is used because the two numbers add to the corresponding third number. Whil estimation we would consider the previous or already estimated story as a bench mark and then estimate the other story. Again the story points vary wit each time. A simple item in the backlog might be 2 for one team and might be 8 for the other. But then that would be the benchmark after which the other stories are estimated. The story points gives the flexibility and buffer to complete the stories.
I am just going to give the Cognizant interview on Saturday and this video I will take as a reference thank you Sunand for producing such a great learning videos, your hard work is paying others and they are being motivated, Why I am saying this coz in my 10+ years carrier’s I didn’t know the name of scrum or agile, but from last 1 month,when I started to watch your videos it’s give me confidence and now I am giving interviews in real world, although I m being failed till now, but being failed you always learn something new. So thanks for this precious knowledge transfer session.
Also my thoughts on tech debts are that if we follow a proper DOD and aceptance criteria, code review, pairing, following code standards etc and make it part of estimation too, we can reduce the chances of major tech debts piling up.
I think sunand you should also add to answer in case sufficient info is not there . 11:00 mins where you are discussing story point in hours I think it good and easy to use story points rather of hours as story points are unit less and it’s easy to weight with numbers rather of hours Because I don’t think a developer can assume or predict and issue is going to take how many hours or minutes . Makes sense ?
Agile brought UAT(User Acceptance Testing) into all stages of the software development process. UAT is a critical part of the testing process where business stakeholders determine the application/feature fulfills its purpose. In Agile development product owners provide input on user story prioritization. the testing goes hand in hand during the sprint. the UAT testers can get involved and become familiar with user stories as per the team's requirement.
That is spillovers Spill over means the stories that are not completed in a given sprint for whatsover reasons and carried forward to the next (upcoming) sprint
