Skip to content

Latest commit

 

History

History
73 lines (43 loc) · 3.58 KB

SCRUM-SOP.md

File metadata and controls

73 lines (43 loc) · 3.58 KB
Raw

SCRUM SOP

Maintainer of this document

  • Sanket Patel
  • Jayati Agarwal

WHY SCRUM

  • To plan out the tasks effectively
  • To provide the maximum information right before the developers start working on the project
  • To estimate the effort effectively
  • To get the definite deadline

Stakeholders

  • Project Manager (PM)
  • Developers

As of now we are not considering designer as a part of SCRUM. They will directly work with the client (in coodination with the PM) to finalize the requirement.

Process

Preparing the requirements

  1. There will be a backlog list which will have all the requirements that are still under discussion. PM will mention the business requirement. The tasks are expected to have Title & Description with acceptance criteria as checklist

  2. S/he may ask for the confirmation from developer if it is clear or not. S/he may assign it to one of the developer(that task representative) as responsible to confirm the requirements in later stage.

  3. Task representative can ask the team leads or anyone in the team if they need input or confirmation.

  4. Once all the inputs are clarified and task representative feel that it is okay to take it into the development. Developer will confirm it by commenting and by adding label "ready-for-development"

  5. In the next sprint planning all the tasks marked as "ready-for-development" will be considered for the estimation

Sprint Planning

  • PM and Developer will meet at preddecide the timing. Ideally it should not take more than 45mins.
  • They should estimate each task(marked as "ready-for-development") on the basis of Fibonacci series (1,2,3,5,8) In which 5 & 8 should be avoided. The estimation are not hours rather consider the numbers symbolize the size of t-shirt like (1-XS,2-S,3-M,5-L,8-XL)
  • Estimate using the https://app.storypoint.poker/ (PM will host this game)
  • Come to a mutual agreement how many points we want to take in the defined sprint. (One sprint should be of one week if there are <=2 devs. If more devs are there then we can go for 2 weeks longer sprint)
  • Start the sprint

Standup Meeting

Every developer has to answer answer to following 3 questions:

  • To help the team to complete the sprint on , what did I completed today?
  • To help the team to complete the sprint on , what will I do tomorrow?
  • To help the team to complete the sprint on , do I have any impediments? Ideally Meeting should not take more that 10 mins.

Ending the Sprint

Ideally sprint should not be extended then the specified date. Once done PM should declare the Sprint review meeting time in channel.

Sprint Review Meeting

It should be organized right after completing the sprint.

The very first rule of the same is to be open minded. This is not to find the anyone's fault but rather the we want to evaluate the process and find as team when we legged if we missed the deadline.

If we achieved the deadline then how many additional story points we can try adding in the next sprint.

Also the meeting should conclude with one improvement that we think we should make in the next sprint. This improvement should be discussed in sprint planning and should be evaluated in the review meeting whether we followed or not.

Initially the process may be overwhelming as it's a new change. But keep faith on it. Worlds's biggest softwares are being made using this process. And with everyone's support we will surely make it smoother.

Any Question or any mistake in the Document?

Please feel free to create issue. We will address it.