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