After a team finishes its Sprint Review, the Retrospective meeting should begin immediately. Of course, there may be a small transition period as non-team members leave a meeting room or as the Team Members go back to their team room. However, there should be no work on the system done between Sprint Review and Retrospective. This quick transition between the two meetings is primarily to ensure that everyone has a clear memory of the Sprint. If there is a gap between the two meetings it can lead to a number of sub-optimal behaviours: team members may do work without the knowledge of the rest of the team, there may be a growing desire to delay the retrospective, or even pressure to skip the retrospective.
Timeboxing is the practice of ending a meeting exactly on time regardless of the state of discussion or the desire of participants. In Scrum, the combined length of the Sprint Review and Retrospective Meetings is determined by the length of the Sprint. For example, a one week long Sprint has Sprint Review and Retrospective Meetings that are timeboxed to two hours in total. It is acceptable for the meetings to take less time, but not more. A two week long Sprint has a Sprint Planning Meeting that is timeboxed to four hours. Keeping the Sprint Review and Retrospective Meetings timeboxed has two beneficial effects: one, the team keeps the overhead dedicated to meetings to a relatively low level, and two, the team learns to do effective inspect and adapt in a very short period of time. If the meetings are not timeboxed, then typically the team will keep going until they are “done”… and break the timebox of the overall Sprint.
The last part of the Sprint is the Sprint Retrospective. This meeting is a private meeting for the members of the Scrum Team (including the ScrumMaster and Product Owner). In this meeting, the Team Members discuss how they did their work during the past Sprint and come up with ways to improve their work in the next Sprint. Scrum does not define any particular techniques to use during the Retrospective meeting. The Retrospective is complementary to the Sprint Review. The Review inspects “what” was done and the Retrospective inspects “how” it was done. The Sprint Retrospective is critical for the team to apply the principle of “inspect and adapt” that is core to Scrum. Missing the Sprint Retrospective is a critical failure of the ScrumMaster’s job to ensure that the principles of Scrum are being used. If a Retrospective is missed once, what may happen is that some Team Members might feel that missing it was not so bad. There will not likely be any immediate consequences to missing the Retrospective. However, the attitude that the Retrospective is not important will be implanted in the team. This then quickly leads to further compromises and eventually, the continuous improvement parts of Scrum are abandoned and the team focuses purely on the execution parts of Scrum. The team will then fail to become a high-performance team since that high-performance state is predicated on systematic, conscious self-improvement of how the team does its work.
Scrum is a tool for product development that uses transparency and fast feedback. The Sprint Review is an open meeting during which the Scrum Team works with all interested stakeholders to look at the results of the Sprint. This meeting is usually dominated by a demonstration of the working increment of software. The stakeholders in attendance at this meeting freely provide feedback about the product which is then used by the Product Owner to update the Product Backlog. This feedback is critical to ensure that the team is staying on-track, that it is building the most valuable possible product features, and that the stakeholders are satisfied with the results. Missing this aspect of feedback makes Scrum only modestly better than non-agile approaches to doing work and should be considered a critical problem to fix as it undermines the whole point of doing Scrum.
Timeboxing is the practice of ending a meeting exactly on time regardless of the state of discussion or the desire of participants. In Scrum, the length of the Sprint Planning Meeting is determined by the length of the Sprint. For example, a one week long Sprint has a Sprint Planning Meeting that is timeboxed to two hours. It is acceptable for the meeting to take less time, but not more. A two week long Sprint has a Sprint Planning Meeting that is timeboxed to four hours. Keeping the Sprint Planning Meeting timeboxed has two beneficial effects: one, the team keeps the overhead dedicated to meetings to a relatively low level, and two, the team learns to do effective planning in a very short period of time. If the meeting is not timeboxed, then typically the team will keep planning until the plan is “done” which usually substantially eats into work time.
The Sprint Planning meeting is the start of the Sprint and is the opportunity for the Scrum Team to discuss what they will build during the Sprint and how they will build it. The focus of the meeting is on choosing Product Backlog Items (the goal for the Sprint) and then breaking those Backlog Items down into a detailed list of tasks (the Sprint Backlog). In Sprint Planning, choosing who will do the work is strongly discouraged. The value of Sprint Planning comes at three levels: first, setting a concrete goal helps with team cohesion and enables high-performance teamwork, second, the planning work helps set expectations with stakeholders and develop a team’s understanding of its own capacity, and third, the time set aside for planning gives the team a chance to think systematically about how to respond to feedback from the previous Sprint.
The length of a Sprint determines how quickly a Scrum Team can “inspect and adapt” to changing circumstances and learning. Scrum, as a tool for product development, sets an upper limit to the duration of a Sprint. In other words, Scrum sets a minimum for the frequency of the inspect and adapt cycle. This ensures that teams using Scrum get at least a certain minimum benefit. Scrum does not set a maximum frequency (minimum Sprint length). If a team has a five-week (or longer) Sprint, the benefits from Scrum rapidly drop off. In particular, you dramatically increase risks associated with short term planning, responding to change, team development, windows of business opportunity, and error detection. Having a cycle longer than four weeks is not Scrum and a team with such a cycle length should not claim to be using Scrum.
Note: some references say that the maximum Sprint length is 30 days or one month. This is considered essentially equivalent to a maximum length of 4 weeks. Please see our article about Factors for Choosing a Sprint Length for more specific and practical guidance about this topic.
The Sprint is the fundamental unit of work when using Scrum. Any product development effort using Scrum is, therefore, divided into Sprints. Sprints are fixed in length so that the team has a predictable amount of time available to them to do work, which in turn assists in both short and long-term planning. By making every Sprint the same length, the Scrum Team learns its own capacity for work. If the Sprint length changes, the rhythm of Scrum is broken and a team will have to re-learn its capacity which usually takes at least a few Sprints. If Sprints are rarely the same length, then the Scrum Team will struggle to do any reliable planning.
This week I met someone while on a personal trip who is in the software business. His company writes software for a very specialized vertical and from everything he said to me, they are an innovative company and do all the right things including empowering their teams to self-organize, regular training for the staff and generally a great working atmosphere.
The company has still been struggling with getting their product to be “deeper” (his word) for their client base.
I was again reminded of a post of mine from a while ago encouraging or providing cross-training or at least some knowledge to bridge the barriers between the software group and the hardware group (link at the bottom of this post). In my environment, I’ve been fortunate to have a network admin sitting with our team. It has prevented many potential problems.
Having been involved in the infrastructure part of IT as well as development, I knew of at least a few products almost immediately that could make his product more compelling to his customers.
To my surprise, I found out his company was only looking at software improvements to their application. He told me how they are continually developing new features but are not considering running on any new platforms.
I mentioned a few technology (hardware) improvements he could consider and I know that by the time he gets home this weekend, he will have taken a look and passed the information on to his team. These improvements could immediately add significant customer retention and usability to his product.
From our discussion, it was also evident that his team would enjoy the challenge of some new platforms to keep encouraged about the future. I’m sure that by the time he reads this, he’ll have some of these technologies in hand :->
As Agile practitioners, it seems, we are so focused on improving our software development cycle, our specific development tasks, our daily or hourly builds, our programming skills, and how we create story points, sometimes we seem to lose track of the big picture… What is the customer going to use it on? This should be fundamental to every developer’s thought processes.
Think to yourself, “HEY, should we be seeing if our software could run on some of the new technologies out there such as Microsoft Surface, some of the new Wireless Devices, or even benefit somehow from new 3D technologies coming out”?
I like to think that developers who are empowered with information about hardware can think of all kinds of ways to use it.
If you’re on an Agile Team or managing one, ask to learn something about the hardware in your environments. Consider some “slack” in your Sprint or some work breaks in your Cycle to allow team members to learn something about new Infrastructure or Hardware products.
Think for a moment if your company is writing software for the Web, the power of a deep understanding of how a load balancer actually works, or my personal favorite, the .NET Cache.
Let it be the teams’ choice of which products though. That will give the best motivation and most likely will be the most enjoyment for everyone.
It will broaden your horizons and perhaps give your team ideas you never knew could even be possible.
If we always just wait for a Marketing Person or Product Owner to come up with interesting ideas, where’s the fun in that?
My previous post – Infrastructure Knowledge for Developers
3D example – Sony 360Degree viewer prototype
Microsoft Surface – Microsoft Surface Web Site
Slack – A good article about slack in XP by James Shore
Sprint – Scrum Alliance
Cycle – Open Agile
The Definition of “Done” is an important concept that helps us understand how to produce working, potentially shippable software at the end of every Sprint. Previously, I wrote about how to expand the definition of “done” from the perspective of the team’s skills, capabilities and work processes. This time around, let’s look at it from a more tactical perspective: how do we identify things that should be added to the definition of “done” and when do we do this?
Identify Repeating Tasks
Early on, the team will make tasks that include every activity that is done to make software out of the features listed in the Product Backlog. This will include all sorts of things including “Build login web service”, “Write unit tests”, “Review code”, etc. Most of these tasks will be thought of in terms of who will be doing them so that throughout the Sprint every person on the team is busy with tasks and there is very little passing of a single task from one person to another. In other words, one task = one person.
It will quickly become clear that there are a number of similar or identical tasks that show up for most items in the Product Backlog. If you have to develop a user-visible feature or function in the software, you always need to check code into your version control system, you always need to do some sort of testing on the code, etc. So you might have tasks in the Sprint Backlog called “Internationalize login panel”, “Internationalize registration panel”, “Internationalize login error panel”, and so on. Every Product Backlog Item has an “Internationalize ….” task. These tasks can be abstracted and the “Internationalize” idea becomes part of the Definition of Done (DoD). It applies for every Product Backlog Item.
You might also have common pairs of tasks where one of the pair is unique to what is being built, and another is attached to it, but common across many pieces of the system. For example, you might have a task “AnonymousUser class” and an associated “Unit test AnonymousUser class”. Then you might have another task “LoginErrorHandler class” and an associated task “Unit test LoginErrorHandler class”. Again, the idea of unit testing then can be identified as part of the DoD. These apply to every Sprint Backlog Task.
Once these required activities or constraints are added to the DoD, you can then stop identifying them as separate tasks. Instead, they get represented in some other way in your work environment: a checklist on a whiteboard, columns in a spreadsheet, or checkboxes pre-printed on the cards you use to write Tasks or Product Backlog Items.
Prepare for Release
The software might need many things done to it or around it to prepare for a release. Often, these things will be put on the Product Backlog as non-functional business requirements. For example, it may be important to write online help for the system and this is not currently being done by the team. The Product Owner identifies that users will need this help and puts it on the Product Backlog. Yo(1) discovers that These things can eventually be moved into the DoD. For example, yo puts “Online Help” in the Product Backlog and prioritizes it somewhere near to the point in the Product Backlog when the system will be ready for a release. The team eventually gets to this item and does it during a Sprint. At this point, the system is “caught up”, but in order to prepare for the next release, the Product Owner will have to put the same “Online Help” item on the Product Backlog again. Instead of doing this, it can be added to the DoD.
It is critical that the team agree to add these things to the DoD, and not be forced by someone. If the team does not feel that it is within their capacity to include something in the DoD, the ScrumMaster should find ways to assist with this: training, etc. Once something is added to the DoD, it must be completed every Sprint in order to have a successful Sprint.
Release/Deploy to Users
There is nothing like actually getting software into the hands of users to find out what “done” really means! Similarly to preparing for a release by adding things to the Product Backlog, the team may have a “release sprint” or a “stabilization sprint”. Everything that is done in one of these special Sprints could and probably should be added to the DoD sooner rather than later! Again, the team must agree to doing this expansion of the DoD and be supported by the organization so that they have the capacity to meet the DoD every Sprint.