Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Scrum Team & Efficiency
- Aditya Kappagantula
Efficiency 𝛼 Predictability
Scrum Team Constitution
Product
Owner
QA
Member[s]
Scrum
Master
UX Team
Software
Architect
Sr.
Developers
Developers
Recurring Team Procedures
 Daily Standup
 Bi-Weekly Planning
 Weekly Stakeholder Meeting[Scrum Master, Product Owner & ...
Daily Standup
 Team members meet, ideally in the morning hours, to update other team
members and stake holders about
 Wh...
Bi-Weekly Planning
 Team meets bi-weekly to identify the project modules/features that it is going to
accomplish in the n...
Weekly Stake Holder Meeting
 A story point of 1 corresponds to 8 hours or 1 day of work.
 The stakeholders [Scrum Master...
Bi-Weekly Demo
 A bi-weekly demo ensures that every team member and stake holder is aware
of the progress made in the pro...
Bi-Weekly Metrics Evaluation
 A schema with below details ensures that stake holders can correctly estimate
the team’s ca...
Bi-Weekly Retrospective Meeting
 After the demo and before planning next sprint, the team should meet to
classify their o...
Story Acceptance Criteria
 Developer breaks stories into achievable tasks
 QA starts writing test cases for the tasks/st...
FAQ I
 Can Scrum Master code?
 Yes. But ideally SM takes very less load. SM’s role is more focused on resolving inter
te...
FAQ II
 Can Software Architect role be replaced with Sr. Developers?
 Yes. The job of SA is to ensure that team sticks t...
Thank you!
 My observations in this presentation comes from my experience of being in
the Software Industry in various ro...
Upcoming SlideShare
Loading in …5
×

Scrum team and efficiency

416 views

Published on

An outline of Scrum Team and Performance improvement from experience.

Published in: Software
  • Be the first to comment

  • Be the first to like this

Scrum team and efficiency

  1. 1. Scrum Team & Efficiency - Aditya Kappagantula
  2. 2. Efficiency 𝛼 Predictability
  3. 3. Scrum Team Constitution Product Owner QA Member[s] Scrum Master UX Team Software Architect Sr. Developers Developers
  4. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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

×