Scrum Process - One Week Sprint

Scrum is a framework for developing software in an agile manner. The tasks are broken down into manageable chunks, the teams are small and self-managed and a great deal of collaboration and communication among team members is necessary to complete the tasks. A typical implementation of the framework involves certain steps, some of which are optional. It is upto the team to decide which steps they wish to implement. A typical iteration(known as a sprint) usually lasts two weeks, but the timeframe is entirely dependent on the team's requirements and goals. In my team we have a one week scrum and following are the steps involved:

• Monday
• Backlog grooming Meeting. This is an hour long meeting between the Product leads and the technical leads.The product team comes to the meeting with a prioritized list of tasks(also referred to as Stories) that are a part of the product road map for the near future.The technical leads analyze the requirements associated with each Story and estimate the size of each Story by associating a numeric value for each. for e.g. a small Story would be a 2, a medium size Story would be a 5 and a large size Story would be an 8 and so on. We tend to use the Fibonacci series as a guideline for our numerical estimates. If a story is large, it can be broken down into smaller Stories and implemented across multiple Sprints.
• From the list above, the Product Manager selects a list of Stories for the week and sends it out to the technical team for review. The technical team members study these Stories prepare for the sprint meeting that happens on Tuesday.
• Tuesday
• Sprint Meeting. This meeting is attended by the entire technical/QA team and the product team. The Product Manager explains the requirements for each Story. For every Story, the technical team members are asked to provide a numerical estimate based on their understanding of the Story. The Story size usually ends up being the value that the majority of the team agree upon.Team members who provide higher/lower estimates than the average are asked to provide an explanation behind their estimates. If they are able to convince the team with their reasoning, there is a good chance of the Story size ending up higher/lower than the previous estimate.
• The technical/QA team breaks down each story into UI/Code/DB/QA components by creating visual cards for each piece. for e.g. a story can have three UI cards, two code cards, one DB card and four QA cards. It is also possible that some stories are purely DB related or purely Code related and do not have UI cards.
• Wednesday
• The technical/QA team starts working on the Stories for the Sprint. The developers start coding and the qa people start writing test cases. The code is pushed into QA as soon as the developers complete coding/unit testing.So while QA tests the features in the QA environment, the developers continue to work on the next items in the prioritized list of stories for the Sprint.
• Thursday, friday
• Team continues development/testing
• Next Monday
• A repeat of the previous Monday but targeting the the next sprint
• Work continues on the current sprint
• Next Tuesday
• A repeat of the previous Tuesday but for the next sprint
• Work continues on the current sprint
• Next Wednesday
• The code from the Current Sprint is pushed into production. This usually involves more work on the QA side.
• The developers begin working on the next Sprint
• Next Thursday
• Sprint Retrospective. This meeting is attended by the product and the technical/QA teams. The pros and cons associated with the Previous Sprint are discussed. The discussions revolve around what was done well, what can be improved and how to streamline the process in the future. The suggestions for improvement are duly noted and applied to the future Sprints.
• The process continues