This is for recording the questions I met during learning and practising Scrum framework. And I will update more questions and try to present my own opinions continuously. If anyone catches something wrong in the content or has different views, please do not hesitate to discuss with me and I would appreciate greatly.

---

Questions

• Q: Scrum is a rule-based framework. Does complying the Scrum’s rules conflict to Agile Manifesto?
  • A: Nope. There are three reasons I have found shown below.
    • ‘Individuals and interactions over processes and tools’ is listed at the first of the Manifesto for Agile Software Development. But it also indicated that it is a case of the relative importance of the values, and not a case of ‘good’ or ‘bad’.
    • The original purpose of Agile is to replace the heavyweight, document-driven processes that existed at the time. Concerning Scrum, it is a lightweight, iterative and incremental framework for managing complex knowledge work. Scrum challenges assumptions of the traditional and sequential approach to product development, and facilitate teams to become self-organise.
    • As one of the Agile Manifesto creators, Jim Highsmith has explained in Agile Manifesto History that ‘the Agile movement is not anti-methodology‘ and ‘we want to restore a balance‘. Such Agile frameworks and methodologies as Scrum, Kanban and XP (eXtreme Programming) have realised the balance by keeping their rules and practices to a minimum given the circumstances but focused on empowering developers of all kinds to collaborate and make decisions together as a group quickly and effectively.

• Q: How many members made up a Scrum Team is appropriate?
  • A: As we know, a Scrum Team consists of three roles, which are the Scrum Master, the Product Owner and the Development Team. The Scrum Master and the Product Owner must be a sole person respectively. With respect to the Development Team, the Scrum Guide has claimed that the number of team members should be at least three and at most nine. Hence, the total number of a Scrum Team should be controlled from five to eleven. However, one specific condition indicated in the Scrum Guide should be considered is that the Scrum Master or the Product Owner can be one of the Development Team members if he or she also participates in the work of the Sprint Backlog. The PRINCE2 Agile manual introduces a typical guide of the Scrum Team size that it should be seven, plus or minus two.

• Q: Is there any effective way to monitor progress during a Sprint?
  • A: There is no specific methods or tools mentioned in the Scrum Guide for monitoring Sprint progress. It’s because the duration of a Sprint is comparatively short, around two to four weeks. So it would be easy to track the progress for the Development Team during this period. However, in order to improve transparency and let everyone know the progress easier, it is a good idea to visualise the Sprint progress like monitoring the progress of the entire project. The burn-down chart is a typical technique that can be employed.

• Q: Should the Sprint Review and the Sprint Retrospective be placed after a Sprint cancelled?
  • A: Once the Product Owner determines to cancel the Sprint, the Scrum Team should review and assess the work has been done and has not been done from the beginning of this Sprint to the present. This is one of the most essential tasks listed on the agenda of the Sprint Review. Although the Scrum Guide does not specify that the Sprint Retrospective needs to be sited at this time, I believe it is appropriate to inspect and adapt the work through this formal event. The actual duration of the Sprint would be less than its fixed duration basically if cancelled, consequently, the duration of the Sprint Review and the Sprint Retrospective should be shortened respectively.

• Q: Will the Increment of each Sprint be released or deployed immediately?
  • A: It depends on the Product Owner. As the sole person accountable for the product, the Product Owner should organise the time to release each Increment in order to maximise value. Thus the Increment delivered during each Sprint must be deemed ‘Done’ and in useable condition regardless of whether the Product Owner decides to release it.

• Q: How many improvements should be implemented during the upcoming Sprint appropriately?
  • A: The Scrum Guide has claimed it should be at least one item selected into the next Sprint Backlog. And I suppose that it is a good idea to prioritise the identified improvement tasks according to their urgency and estimated effort, and then select the items with the highest priority and within the tolerable effort based on the result. In this manner, the Scrum Team can ensure that only a few improvements to the process are suggested, as opposed to working on too many of them at the same time.

• Q: Can the sprint end early if all tasks in the Sprint Backlog have been completed and the Sprint Goal is reached?
  • A: No. The Scrum Guide illustrates that ‘Once a Sprint begins, its duration is fixed and cannot be shortened or lengthened’. However, there would be the case if the Scrum Team members have accomplished all work before the Sprint end date. In this situation, the Scrum Team must keep self-organising to find out and work on correct work in the remaining duration. There is a typical list of the work the Scrum Team can perform during this time.
    • Continuously refine Product Backlog items to ‘Ready’;
    • Identify and implement activities that improve quality or productivity or work;
    • Participating in practices or trains to adopt and understand Scrum and Agile better;
    • Learning or improving other relevant skills to become more cross-functional;
    • etc.

• Q: Can the duration of a Sprint be shortened or lengthened?
  • A: Yes. The Scrum Team can make the decision for changing the Sprint length together as more is learned. Scrum is founded on empiricism and there is no specific limit of shortening or lengthening the Sprint duration if the Sprint has not commenced. Hence, changing the Sprint duration can be seen as an action that is identified and recorded in the improvement list for improving work and fitting the Scrum Team’s goals better during the Sprint Retrospective. In addition, each event must change its duration according to the new Sprint length.

• Q: Can the duration of an event within a Sprint be shortened or lengthened?
  • A: Yes. The Scrum Guide demonstrates that ‘The remaining events may end whenever the purpose of the event is achieved, ensuring an appropriate amount of time is spent without allowing waste in the process‘. Consequently, if the Scrum Team has recognised that the prescribed length of a specific event is too much enough or too little for achieving its purpose, the Scrum Team should reset the event duration in the Sprint Retrospective for the upcoming Sprint. But the team should comply with the rules that define the maximum duration of each event in the Scrum Guide. Moreover, there is another situation that the duration of each event must be changed as mentioned in the previous question.

• Q: Can the content of Sprint Backlog be modified during the Sprint?
  • A: AgileAlliance has presented its answer when introducing Scrum, which is ‘Once the team and product owner establish the scope of the Sprint as described by the product backlog items no more items can be added to the Sprint Backlog. This protects the team from scope changes within that Sprint‘. But I DO NOT agree. Let’s take a look from the following perspectives.
    • Sprint Goal. This is an objective defined in the Sprint Planning by the Scrum Team that the team MUST satisfy by the development work throughout the Sprint. And the Scrum Guide suggests that ‘The Sprint Goal gives the Development Team some flexibility regarding the functionality implemented within the Sprint‘.
    • Sprint Backlog items. During the Sprint Planning meeting, the selected Product Backlog items are broken down into a set of tasks presenting the HOW of the Sprint Goal met.
  • In conclusion, we can know that one thing must not be changed within the Sprint, which is the Sprint Goal, instead of the scope. And the Sprint Backlog items can be modified during the Sprint to satisfy the Sprint Goal better. There is also some evidence supporting my view in the Scrum Guide, such as ‘Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned‘ and ‘If the work turns out to be different than the Development Team expected, they collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint‘.

Remaining Questions

• Q: Can the Sprint Goal be modified during the Sprint?

• Q: One of the elements included in the Sprint Review is ‘the development team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved’. Is it more likely to be done during the Sprint Retrospective instead of the Sprint Review?