1. Scrum Team & Efficiency
- Aditya Kappagantula

2. Efficiency 𝛼 Predictability

3. Scrum Team Constitution
Product
Owner
QA
Member[s]
Scrum
Master
UX Team
Software
Architect
Sr.
Developers
Developers

4. Recurring Team Procedures
 Daily Standup
 Bi-Weekly Planning
 Weekly Stakeholder Meeting[Scrum Master, Product Owner & Software
Architect]
 Bi-Weekly Demo
 Bi-Weekly Metrics Evaluation
 Bi-Weekly Retrospective Meeting
 Optional Hip-Sprint once in every 4 sprints [Time dedicated to resolve bugs
that got introduced in development or refactor code]

5. Daily Standup
 Team members meet, ideally in the morning hours, to update other team
members and stake holders about
 What they worked on the previous day
 What they plan to work today
 Any unforeseen risks/dependencies discovered
 Typically a standup meet should not exceed more than 10 minutes at max for
a team of 5 Developers, 2 QA, 1 PO, 1SM [UX team members and S/W
Architects generally don’t have daily updates]

6. Bi-Weekly Planning
 Team meets bi-weekly to identify the project modules/features that it is going to
accomplish in the next two weeks [a sprint]
 Product Owner, Software Architect and Scrum Master breaks the work to be done
into multiple stories well ahead before the meeting.
 Team members pick the stories from a lot or, SA and SM assigns each story to a
team member based on their previous related stories.
 Team estimates the number of development hours including automated test case
development time and votes points [1,2,3,5 or 8] for each story, all at a time.
 A discussion happens between developers and software architect to arrive at a
consensus on the points to be assigned to the story and the story is accepted for
development
 On an average a developer who is well acquainted with the project should be able
to accomplish 6-10 points per sprint

7. Weekly Stake Holder Meeting
 A story point of 1 corresponds to 8 hours or 1 day of work.
 The stakeholders [Scrum Master and Software Architect, PO is optional] meet
once a week is completed from planning to understand if all the stories which
are less than 3 points in value have already been accepted as completed.
 Any “failed to meet acceptance criteria stories” are identified and SA
investigates into why the plan has failed along with the corresponding
developer.
 A spike story is added to current or next sprint as per requirement.

8. Bi-Weekly Demo
 A bi-weekly demo ensures that every team member and stake holder is aware
of the progress made in the project.
 It ensures in building a confidence in the stake holders that the project will
hit its deadline and ensure successful Return On Investment
 It also provides a chances for team members to showcase their work to their
peers before it can be criticized by end-users

9. Bi-Weekly Metrics Evaluation
 A schema with below details ensures that stake holders can correctly estimate
the team’s capacity.
 No. of points brought into the sprint during planning
 No. of points accepted by the last day of the sprint
 Percentage of completion
 Percentage of failure stories
 No. of stories brought into the sprint
 No. of stories accomplished
 This ensures that team velocity is calculated accurately and thereby gives the
Product Management team a nearly accurate estimation of project
completion date.

10. Bi-Weekly Retrospective Meeting
 After the demo and before planning next sprint, the team should meet to
classify their observations of the current sprint merits and demerits as:
 Positive
 Negative
 Can be improved
 Scrum Master, Software Architect and Product Owner should take the
responsibility to improve on the comments that fall in the sections
“negative” and “can be improved”
 This should be evaluated for improvement in the next sprint retrospective
meeting.

11. Story Acceptance Criteria
 Developer breaks stories into achievable tasks
 QA starts writing test cases for the tasks/story together
 Once development is complete, developer pushes the code to the main code
repository
 QA starts testing the developers version of main repository
 Once developers version gets approved into main repository, QA tests main
repository
 Only a Product Owner can accept a story.
 A QA will record any minor deflection from the specs or expected behavior as a
defect and developer has to close them.
 To accept a feature/story is dependent on the Product Owners judgement on the
criticality of defects.

12. FAQ I
 Can Scrum Master code?
 Yes. But ideally SM takes very less load. SM’s role is more focused on resolving inter
team dependencies.
 Can PO and SM be the same person?
 Yes. Multiple roles are accepted as long as the team performance is good.
 Is every step in above slides mentioned mandatory?
 No. Nothing is fixed in Scrum Process. Every team can tweak every aspect as long
as productivity and predictability are on track.
 Is Automated QA developer’s job?
 Yes. Because developers know the context better than others. However, QA are
free to add more test cases.

13. FAQ II
 Can Software Architect role be replaced with Sr. Developers?
 Yes. The job of SA is to ensure that team sticks to the Organization’s Codebase
Maintainability and Scalability. If Sr. Developers can achieve it, SA can be replaced.
 Is it mandatory to have Sr. Developers and Jr. Developers?
 No. But it is a good practice to have a well balanced team so that next generation
products can be well envisioned.
 Is tracking every defect important?
 Yes. It is vital for a perfect release and to ensure that agile methodologies can be
applied to product development
 Can PO accept features with defects?
 It depends on the vitality of the feature in PO’s perception. It is good to accept
stories with minor defects and resolve them in hip sprints if that helps the team
maintain its velocity.

14. Thank you!
 My observations in this presentation comes from my experience of being in
the Software Industry in various roles for 4+ years and working for a variety of
firms ranging in
 Freelancer
 Single Man Startup
 Small Scale Software Startup
 Enterprise Software Industry
 I would be glad to receive any constructive criticism or discussions on how
software deliverable predictability can be achieved/improved.
 Feel free to reach me on my email: kappagantula.aditya@gmail.com