Sorry for the break in the flow of info… things will be quiet here for three days (Wed, Thu, Fri) and will continue as normal on Monday. Thanks for all your visits, comments and re-tweets!
Estimation – The Bucket System [pdf] – printable reference version of this article.
The “Bucket System” is a way to do estimation of large numbers of items with a small to medium sized group of people, and to do it quickly. The Bucket System has the following qualities which make it particularly suitable for use in Agile environments:
The Bucket System of estimation works as follows:
Some important points to consider:
The bucket system is a good alternative estimation method to try instead of Planning Poker. It is much faster than Planning Poker and still gets reasonable results.
Scrum considers tracking the time individuals spend on individual tasks to be wasteful effort. Scrum is only concerned about time when it comes to the time boxes of the Sprint and Sprint meetings. Scrum also supports sustainable development, which implies working sustainable hours. When it comes to the completion of tasks, the team is committed to delivering value. The tasks in the Sprint Backlog represent the remaining tasks that the team has identified for delivering on its committed increment of potentially shippable value for the current Sprint. The tasks themselves have no value and therefore should not be tracked. Scrum is only concerned about burning down to value delivered. Time spent on individual tasks is irrelevant. What if I track my hours or my “actual” time on tasks? This promotes a culture of “bums in seats” – that it is more important for people to be busy at any cost instead of getting valuable, high-quality results. This also promotes bad habits such as forcing work into billable hours even though it is not. Overall, time tracking in a Scrum environment does much harm and can undermine the entire framework.
Inside the Scrum Team, including the Product Owner and the ScrumMaster, no individual should report to any other individual. The team reporting structure should be flat. This does not necessarily mean that all Team Members are peers in the org chart. For example, one team member could be quite senior, and another quite junior. However, for the Scrum principle of self-organization to work effectively, individual Team Members should have no concern about what their “boss” wants them to do. Instead, within the Scrum Team, there should be a completely safe environment for individuals to volunteer for tasks, raise obstacles, provide candid feedback to any other Team Member, and have a mutual sense of commitment to the work of the team. If the Scrum Team is absent of reporting relationships then it has a much higher chance of becoming a high-performance team. If there are reporting relationships within the Scrum Team there are often significant obstacles to full openness and self-organization and this, in turn, will significantly hamper the performance of the team.
All tasks done by individuals on a Scrum Team must be chosen voluntarily. If one Team Member, in any way, tells another Team Member what task to work on, this breaks the principle of self-organization that is essential to creating a high-performance Scrum team. Team leads, project managers, functional managers and other people in roles of authority to assign tasks must give up that authority completely when it comes to the people on a Scrum team. This self-organizing behavior allows individual team members to consider their own talents, capacity, interest, motivation etc., when choosing a task. All of those inner conditions are not as well known by other people and so assigning tasks tends to be sub-optimal. When a Team Member considers those inner conditions about him or her self, and also takes into consideration the needs of the team, an optimal task choice can be made. If someone in a position of authority does assign tasks, it creates a habit of deferring to authority which quickly destroys any possibility of a high-performance team developing.
The Sprint Retrospective meeting supports the Scrum value of Openness and the principle of inspect and adapt. This rule of Scrum also aligns with the Agile Manifesto principles “at regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” In-person attendance of all Scrum Team members allows for the fullest level of openness among Team Members which in turn is necessary to use the Retrospective to find improvements in how the team functions. If even one team member attempts to attend this meeting by any other means, either by phone or even video conferencing, efficiency and effectiveness of the openness and inspect and adapt becomes compromised. Compromise on these principles yields compromised collective ownership of improvement efforts. Lack of in-person participation increases the likelihood that the team will fail to implement improvements because the openness and inspect and adapt will lack effectiveness. This, in turn, hinders the team from reaching a high-performance state.
The Sprint Review meeting supports the Scrum value of Openness and the principle of inspect and adapt. This rule of Scrum also aligns with the Agile Manifesto principles “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation” and “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” In-person attendance of all Scrum Team members allows for the fullest level of openness among Team Members and effective communication of feedback from stakeholders reviewing the product increment. If even one team member attempts to attend this meeting by any other means, either by phone or even video conferencing, efficiency and effectiveness of the openness and inspect and adapt becomes compromised. Compromise on these principles yields compromised collective ownership. The successful delivery of the valuable software requires full commitment on the part of the whole team. Lack of in-person participation increases the likelihood that the team will fail to deliver on its Goal because the openness and inspect and adapt will lack effectiveness.
The Daily Scrum meeting supports the Scrum value of Openness and the principle of self-organizing teams. This rule of Scrum also aligns with the Agile Manifesto principle “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” In-person attendance of all Scrum Team members allows for the fullest level of openness among Team Members. If even one team member attempts to attend this meeting by any other means, either by phone or even video conferencing, efficiency and effectiveness of the openness and self-organization becomes compromised. Compromised self-organization yields compromised collective ownership. The successful delivery of the Sprint Goal requires full commitment on the part of the whole team. Lack of in-person participation increases the likelihood that the team will fail to deliver on its Goal because the openness and self-organization will lack effectiveness.
This rule of Scrum aligns with the Agile Manifesto principle “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” In-person attendance of all Scrum Team members allows for the plan to unfold with minimal communication overhead and for the team to keep the meeting within the short time-box. In-person attendance also allows the team to effectively collaborate in the work of creating the plan. The efficiency and effectiveness of the Product Owner’s presentation of the Product Backlog is optimized as well as the Development Team’s ability to collaboratively assess and select what it can and will accomplish in the Sprint. It also allows for everyone to be clear about the Sprint Goal and why the Development Team is building the increment. In-person attendance also allows the Development team to efficiently and effectively come to a decision as to how it will build the increment of functionality. In-person participation of all team members also increases the likelihood that the team will create the right design for the increment. If even one team member attempts to attend this meeting by any other means, either by phone or even video conferencing, efficiency and effectiveness of the planning becomes compromised. Compromised collaborative planning yields compromised collective ownership. The successful delivery of the Sprint Goal requires full commitment on the part of the whole team. Lack of in-person participation increases the likelihood that the team will fail to deliver on its Goal because the planning will lack effectiveness. People are prone to estrangement from hazy goals reached through ineffective planning. In-person planning, therefore, is paramount to succeeding with Scrum.
The Agile Manifesto is the founding document of the Agile movement. It can be found at http://www.agilemanifesto.org and if you haven’t read it, it is strongly recommended! Living values and principles is an act of striving for excellence. There are no mechanisms in Scrum to force people to live the values and principles of the Agile Manifesto. Scrum relies on individual team members to strive to develop an understanding and practice of Agile values and principles in and of their own volition. If Team Members do not live the values and principles of the Agile Manifesto in their team many other things will take priority such as creating a complex document. The team could think of Scrum as a tool for project delivery, without really working to change the culture of their organization. Since Scrum empowers individuals and makes obstacles visible, if the team doesn’t live the Agile Manifesto principles then they may be disconnected from the roots of Scrum and make it a lesser version of itself, sometimes known as Scrumerfall (where you blend some elements of Scrum with other elements of waterfall which provides little to no benefit).
As a Team Member, it is my job to figure out how to solve a problem or request that is stated by a Product Backlog Item (PBI), with the help of my team. It is the responsibility of the Product Owner to give us the vision of the product and decide how much scope is to be done to satisfy the PBI. One simple way to think about this concept is that the Product Owner is responsible for the “what” and “why” and the Scrum Team is responsible for the “how” and “who”. If the Team Members decide on the product vision by themselves, they run the risk of misinterpreting features, moving down a path that is not valuable or even creating work disconnected from the needs of those who will be using the software. If the Team Members choose their own scope they may do much less than is needed or much more than is required. There is a balance in the Product Owner providing vision and scope, and the Scrum Team providing knowledge and experience in its execution.
The Definition of “Done” for a Scrum Team makes transparent how close the team’s work is coming to being shippable at the end of every Sprint. Expanding the Definition of “Done” until the team is able to ship their product increment every Sprint is a process that every Team Member helps advance. Team Members expand the Definition of “Done” by learning new skills, developing trust and gaining authority to do work, automating repetitive activities, and finding and eliminating wasteful activities. When every Team Member is systematically expanding the Definition of “Done”, the team builds its capacity to satisfy business needs without relying on outside people, groups or resources. If Team Members are not actively working on this, then many of the obstacles to becoming a high-performance team will not be discovered.
Scrum Team Members, excluding the ScrumMaster and Product Owner, must be completely open-minded to learning new skills. Skills can be technical, business, personal, tools-based, etc. A Team Member is sensitive to the needs of the Scrum Team and will learn skills by multiple means as the needs of the team evolve. A Scrum Team where people are not willing to learn new skills will suffer from bottlenecks, time pressure, quality problems, and often will become generally demoralized as the willingness of some people on the team turns into apathy and cynicism when others refuse to learn. In a team where everyone is willing to learn new skills, there will be a consistent raising of capacity and the team will be able to do more and more work more effectively. This attitude is a key requirement for the formation of high performance teams.
The principles of openness and transparency include being able to be truthful about ways that you are struggling. A Team Member must share their struggles with their Scrum Team and with the ScrumMaster so that the team, at least, knows your status. Without that visibility, the Scrum Team may make decisions that are difficult or impossible to implement due to hidden obstacles. At every Daily Scrum, each Team Member should think carefully about the challenges they are currently facing, and share those challenges. The ScrumMaster cannot do a good job without that transparency since a core part of their work is to deal with obstacles. If a Team Member fails to be open about obstacles, or fails to recognize something in their environment as an obstacle, this can slow the team in its progress towards becoming a high-performance team. Obstacles that persist for a long period of time simply because they are not openly discussed can have a demoralizing effect on the team. On the other hand, a team that creates full visibility into their obstacles can enlist the help of stakeholders, work together to overcome those obstacles, and systematically become better and better at doing their work.
Every Scrum Team Member should be working on tasks in the Sprint Backlog. Generally speaking, this should be one task at a time with little or no work done on work that is not on the Sprint Backlog. The visibility of the Sprint Backlog is an important part of Transparency within the Scrum Team. As well, doing one task at a time helps with Focus, another of Scrum’s values. If team members follow this rule, then the work of the Sprint is done in a reliable way. When team members take on multiple tasks simultaneously or when they take long breaks to do non-Sprint Backlog work, then the team’s focus is substantially diminished and overall productivity suffers.
