Explore

Sprint Accountibility?

This is a draft; Anything not explicity written here is not my responsibility.

Process

Sprint duration two weeks by default; should be discussed and approved by CTO if needs to be changed.

Product Managers should create new or change task in backlog. QA Engineers should create bug fix tasks in backlog.

I will pick task from backlog considering product roadmap and stakeholder priority.

I will discuss with team to verify if picked tasked can be completed in the Sprint. In case team feels they cannot; then CTO will help me to understand & facilitiate if he / Stakeholders feel otherway.

A new task or change in backlog should have approved PRD(s) and UI / UX by Tech Lead, CTO, and Stakeholders to be added in a Sprint.

We encourage no PRD and and UI / UX changes after a Sprint has began. However, for unavoidable circumstances, even for minor change, team should be allowed to increase their required or promised timeline. In case that exceeds Sprint duration, CTO and Stakeholders will be open and flexible to it. Such tasks should be continued to next sprint(s).

A bug fix task in backlog should approved PRD(s) and UI / UX by Tech Lead, CTO and Stakeholders if needed.

In a Sprint, there will be a minimum of 1 day reserved for fixing sudden production bug which were not in backlog.

After each Sprint, there will be one day gap to review last sprint and discuss next Sprint. But if team requires more time to declare timeline for the next spint, then CTO and Stakeholders should be open and flexible to keep more than 1 day gap in between those sprints.

In case of events such large number of unpexted production bug, resource unavailibity, unnanimous misunderstanding of a task or disruption casued by an act of God etc. CTO and Stakeholders and will be obligated to increase the Sprint time or restructure Sprint to move task to some other Sprint followed by Sprint review.

Even though I personally plan to move to Sprint which will release / ship the new task / changes in that Sprint, but we need to consider cases when dev can complete but QA needs more time to test then the allocated time of the Sprint. In such cases, testing and releasing shall go to next Sprint, not some other sprint in future.

As I am not a professional Scrum Master nor it is my career goal, I should be given at least 5-6 sprints to figure out and improve the process. In this first 5-6 sprints, I expect heavy help from Product, CTO and CEO. CTO and Stakeholders should explicity help me if the process needs improvement rather than putting me on the stand.

In case a team member is done with their task in a Sprint, I will not be responsible to pick another task for them from backlog. Team members can be encouraged to use the time for knowledge sharing, refactoring, or preparing future work, rather than defaulting to pulling new scope. In order to mitigate idle time of team members and ensure maximum efficiency of the team, CTO will provide me continious support in planning of Sprints.

To ensure consistent communication and prevent misaligned expectations, no commitments to customers regarding delivery timelines should be made without my review and confirmation.

To maintain focus and predictability, no new features, tasks, or deadlines will be added to an active Sprint without my prior agreement. If urgent scope additions are unavoidable, they must be discussed and approved together with me and documented clearly in the project management tool, including impact on other Sprint commitments.

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.