How PD works in Agile team

By Dingshan Li

PD (Product designer) is very important role in software development. They will provide detail requirements specification and business workflow, UI workflow. In traditional software development process, PD will prepare the detail requirement design document before develop team start to make software design. This kind of process will work pretty well if the requirements are clear and relatively stable. Also, there are enough PD resources to make the complex documents. But most of time, we cannot figure out the whole requirements clearly at the start stage. And the scope change is often happen. Another factor is that PD always need to work on more than one product and it is very difficult for them to spend much of time to work out a detail design document. So, what can we do to deal with this kind of issues?

Agile provides a methodology or framework for the team to develop software under the situation of changing scope. By focusing on high value requirement, separating the long lifecycle to be several short iterations and guarantee fully-test in each iteration, it can provide high-quality and expected software to the client. In this kind of framework, how PD works in the team? How they collaborate with others

Continue reading this article.

Can Scrum Support Six Sigma?

By Heitor Roriz Filho

INTRODUCTION

This article discusses briefly how Scrum could support Six Sigma projects. Issues of whether Six Sigma is used specifically in software or other product development are not considered. If you ask yourself "Why should Scrum support Six Sigma projects?" I can promptly reply, "Why not?"

Moreover, the question of how Scrum, a lightweight framework for project management and other predictive and detailed methodology have led to process improvement has already been addressed in [2] [3] [4] [7].

SIX SIGMA ASPECTS OVERVIEW

Six Sigma can be considered a detailed and structured methodology to execute projects in a company. To ensure the success of Six Sigma methodology implementation, some critical factors must be verified. A study by McAdam and Lafferty reveals the necessity of employer's empowerment applied with the right tools and methods, in order to achieve the Six Sigma proposed goals in an autonomous and responsible way [14].

Six Sigma as a new paradigm of excellence can result in a huge amount of investment, and it can be questioned if there are other methods that require fewer resources and achieve similar results. Six Sigma still has a long road ahead until it can be accepted as a change philosophy applied to companies in general [14].

In parallel to this movement, another methodology called Lean Manufacturing or Lean Production was developed, and the union of these two process improvement methodologies is called Lean Six Sigma. Originally focused on improvement with a special attention to losses reduction, the concept became one of the most important points of Taiichi Ohno's philosophy, the mentor of the Toyota Production System (TPS). Combining JIT, KANBAN, Quality Circles and CEP, he focused on saving Toyota from a big crisis during the 50´s, which they not only overcame but also won the Japanese Quality Award, the Deming Prize.

Nowadays, many consulting companies look for Six Sigma experts as well as experts in Program and Lean Production, and even though training costs remain above average, many companies are still embracing these programs. On the other hand, some online communities such as TreQna (www.treqna.com) are freely sharing Six Sigma and Lean Production concepts, ensuring many options to people interested on acquiring such knowledge.

The deployment of any program or strategy always depends on people's behavior. In [18] this behavior is divided into two independent and important groups, the top management and the people in charge of the program implementation. The behavior of these two groups is strongly related to their creeds and values, and significantly contributes to the implementation success of a process improvement program such as Six Sigma.

SIX SIGMA ROLES AND METHOD

Six Sigma is based on a people structure of three main roles, Champions, Black Belts, and Green Belts working in a framework such as DMAIC (Define-Measure-Analyze-Improve-Control), a 5-phase method based on PDCA and focused on problem-solving. The Champions have the responsibility to properly define the project scope (during the Define phase) and support the project during the other phases. The Black Belt has the responsibility to communicate frequently with Champions and team members during the project execution, and act as a project leader. Green Belts act as team members and play an active role in the Measure, Analyze, and Improve phases. Finally, all members work together to ensure the sustainability of improvements during the Control phase.

THE SCRUM ROLES

Scrum is focused on its process, three roles, and some artifacts. The three roles in Scrum are the Product Owner, the ScrumMaster, and the Scrum Team.

The artifacts in Scrum are the Product Backlog, the Sprint Backlog, and the Burndown Graph. The Product Backlog contains a prioritized list of the client's needs, i.e., all activities to be performed in order to get the product done. This list is prioritized according to the client necessities; the more business value, the higher on the list the activity will be placed. The Sprint Backlog is a list of activities broken into tasks that are selected in the beginning of a Sprint (a time-boxed iteration usually ranging from two to four weeks). A Burndown Graph displays the remaining work in a Sprint. The literature about Scrum artifacts is vast. More on the artifacts can be found at [10] [11] [12].

The Product Owner (PO) has several responsibilities in a project ranging from defining the product vision to managing the Return on Investment (ROI). The PO represents the needs of the client in a project and is in constant and close contact with the client as well as with the Scrum Team and ScrumMaster. The ScrumMaster is a facilitator in the Scrum process. He is the one responsible for ensuring that Scrum is correctly understood and is correctly followed by the team and PO. The Scrum Team is comprised by those who actually perform the activities necessary to get the product done during the several Sprints.

The Product Owner builds the Product Backlog, a prioritized list of the client's needs. These needs are expressed and/or written in the form of User Stories [14]. Before starting a Sprint, the Scrum Team, the ScrumMaster and the Product Owner perform the planning in a ceremony called the Sprint Planning Meeting. During this meeting the stories with higher priorities are thoroughly discussed and understood by all involved in the process. The Scrum Team then takes these stories and breaks them down into activities, which are the tasks needed to be performed in order to get each story done. These activities comprise the Sprint Backlog.

With the Sprint Backlog the Scrum Team starts to perform in the Sprint. During each day of the Sprint, the Daily Scrum takes place. During this 15-minute standup meeting, each member of the team answers three questions: What did I do yesterday? What I am going to do today? Are there any impediments? It is important to point out that the ScrumMaster acts as a facilitator during the whole process. During the Sprint he will be the one responsible to check whether the Scrum Process is being correctly followed and will protect the team from external interferences, including facilitating the removal of all possible impediments for the tasks.

At the end of the Sprint an increment of the product is delivered. Two ceremonies are performed, the Sprint Review, where the potentially deliverable product increment shall be accepted by the Product Owner, and the Sprint Retrospective, where the team discusses improvements that can be done during the next Sprint. These improvements range from changes in artifacts to better personal interaction.

We can see in this section that Scrum has a very simple yet immutable core process. It is important that this remains unchanged; otherwise we will not be speaking about Scrum, but something else. The next section will talk about how to blend this Scrum kernel into Six Sigma's.

BLENDING SCRUM INTO DMAIC

Scrum is extremely critical regarding the pureness of its architecture while Six Sigma is focused on reaching high quality products performance through variation reduction. The combination of these two concepts can be extremely powerful to bottom-line applications, mainly because Scrum has a strong alignment with lean principles. Furthermore, Six Sigma implementations blended with Lean principles (Lean Six Sigma) can be found in the industry and have become subject to many studies. We believe this diversity ranging from Lean and behavioral aspects and thoughts to predictive and detailed ideas can lead to better performance [5]. As pointed out by [15], Six Sigma should not focus only on the "how to do" the continuous improvement, evaluating the processes performance and business results, but also verify the people engagement and motivation. Therefore, both concepts can combine and complement each other, improving results.

Focusing on high quality products performance and establishing metrics based on statistics, Six Sigma manages a strong, continuous improvement of the manufacturing process. On the other hand, Scrum is a people-centered approach. Its essence surrounds its process and it has a profound effect on people's behavior: it affects the level of commitment in projects tending to facilitate the adoption of new ideas, i.e., it fights the resistance to change.

I start by grouping Six Sigma in six perspectives as shown in Figure 1 below.

The focus on clients' perspective aims to determine the VOC (Voice of Client) variable. Scrum has a very strong focus on the client. The client has its voice through the role of the Product Owner, which acts as a proxy of the client and communicates to the Scrum Team her vision and goals in the scope of the project. The fourth perspective is strongly based on statistical measurements. While Scrum has no predefined statistics in its core, it does aim to achieve improvement through collaboration and communication, i.e., developing strong and fruitful interactions among people. For these two perspectives it does not matter what process tool is used: DFSS, DMAIC, DMADV, etc.

DMAIC is one of the tools found in the perspective number 3 above. The steps defined by DMAIC is where Scrum can produce more tangible results and establish how both concepts intermingle as this is where project management initiatives in Six Sigma are located.

In order to apply Scrum in a Six Sigma project, we propose the following correlation among the roles of both concepts, shown in Figure 2 below.

One of the common mistakes that organizations make when implementing statistical thinking as in Six Sigma implementations is using measurement for motivational purposes [6]. Scrum as a PM framework can collaborate with Six Sigma leveraging the commitment of the team in both Operational and Managerial levels as depicted in Figure 3 below.

In order to blend Scrum and Six Sigma concepts, we consider that an organization comprises two parts, namely the managerial and operational level. We can then visualize the enterprise in terms of project management, where in the managerial level we find all types of executive work, except project management itself. Project management activities can be found in the operational level.

In the managerial level, Scrum would leverage the premise of any Six Sigma implementation, i.e., the support of senior executives. Applied to this level one can setup business-specific Sprint and Product Backlogs and run their activities according to Scrum's Heart and Soul [11]. This approach has been termed Executive Scrum by Magno [8].

The operational level is where DMAIC comes into play. Defining, measuring, analyzing, improving, and controlling are done during project execution. Champions (executive board) determine priority of upcoming tasks according the last DMAIC cycle. This prioritization comprises the Sprint Backlog for one Sprint.

CRITICAL ASPECTS TO CONSIDER

Six Sigma's VOC is a critical aspect of the methodology. This is generally not considered as much as it should be in any Six Sigma implementation. Deming's system of profound knowledge has four points [16]:

1. Appreciate the system.
2. Understand variation.
3. Theory of knowledge: PDCA as constant improvement.
4. Psychology. In our case, understand what engages people in their work.

Generally, Six Sigma is seen as being focused mostly on points 2 and 3. The point is that it does not matter how precise or improved a process can be if it does not meet the client's needs. Points 1 and 4 of Deming's system are those that interface with client's needs. This is where Scrum comes into play, as it has a strong focus on this and aims to work in collaboration with clients during every Sprint.

REFERENCES

[1] H. TAKEUCHI AND I. NONAKA, The New New Product Development Game, Harvard Business Review, 1986.

[2] JAKOBSEN, C. R. AND SUTHERLAND, J. Scrum And CMMI – Going From Good To Great. Are You Ready-Ready To Be Done-Done? In Agile 2009, Chicago, 2009.

[3] SUTHERLAND, J. ET AL. Scrum and CMMI Level 5: The Magic Potion For Code Warriors. In Agile 2007. IEEE Computer Society.

[4] GLAZER, H. ET AL. CMMI Or Agile: Why Not Embrace Both! Software Engineering Institute, Carnegie Mellon University. November 2008, Technical Note Cmu/Sei-2008-Tn-003.

[5] PAGE, S. The Difference: How the Power of Diversity Creates Better Groups, Firms, Schools, and Societies. Princeton University Press, 2007.

[6] PAULK, M. C. AND HYDER, E. B. Common Pitfalls in Statistical Thinking. Carnegie Mellon University. In ASQ SOFTWARE QUALITY PROFESSIONAL, VOL. 9, NO. 3, JUNE 2007, PP. 12-19.

[7] PAULK, M. C., Extreme Programming from a CMM Perspective. IEEE Software, Vol. 18, No. 6, November/December 2001, pp. 19-26.

[8] MAGNO, A. Scrum Executivo. AdaptWorks, São Paulo, 2007.

[9] SIVIY, J. M. AND FORRESTER, E. C. Accelerating CMMI Adoption Using Six Sigma. Carnegie Mellon University, Software Engineering Institute, 2004.

[10] SCHWABER, K. The Enterprise and Scrum. Microsoft Press, 2007.

[11] SCHWABER, K. Agile Project Management with Scrum. Microsoft Press, 2007.

[12] SCHWABER, K. AND BEEDLE, M. Agile Software Development with Scrum. Prentice Hall, 2001.

[13] http://www.scrumalliance.org. Scrum Alliance website.

[14] COHN, M. User Stories Applied.

[15] MCADAM, R. and B. LAFFERTY, A multilevel case study critique of six sigma: statistical control or strategic change? International Journal of Operations & Production Management, 2004. p. 530-549.

[16] http://deming.org/index.cfm?content=66. The W. Edward Deming Institute. Accessed: 2010-01-29.

[17] CORONADO, R.B. and J. ANTONY, Critical success factors for the successful implementation of six sigma projects in organizations. The TQM Magazine, 2002. p. 92-99.

[18] PFEIFER, T., W. REISSIGER, and C. CANALES, Integrating six sigma with quality management systems. The TQM magazine, 2004. pp. 241-249.

Power of the Post-it

By Aaron Conoly

When it comes to Scrum, I'm a newb. I got my CSM certification last year and have been slowly learning how best to introduce Scrum to my organization. Recently, I started using Post-its to enhance how we use Scrum.

Just to be clear, I am not the official spokesperson for 3M products (although that doesn't sound like a bad gig; in fact, 3M, if you're reading this, call me!), and I haven't received any kickbacks for endorsing the Post-it (again, 3M, call me!).

Anyway, I'm something of a hero around the office, because I solved two problems with a simple, yet extraordinary item, the Post-it. A year ago, we were up to our necks in missed deadlines, broken promises (and, at times, dreams), and shoddy workmanship. So, we decided to seek out a new way of getting things done. It so happens that we came across Scrum, which, incidentally, focuses heavily on getting things DONE. And, even though we aren't a software company, we were drawn to Scrum because it provided a fresh, effective way of producing acceptable product. After doing more research, we decided to send one of us to a CSM course. The next month, I spent two days learning about Scrum, and at times, nodding my head and pretending to understand conversations about "Java software architecture," and "version control systems." Later, I took the exam and got certified. I returned to the office triumphant, a veritable Jedi Master of all things Scrum.

Then my boss asked me a terrifying question. "Well," she said, "what now?" After stumbling and bumbling over how exactly to say let me get back to you on that one, I retreated to my desk, defeated. Suddenly I wasn't a Jedi Master, heck, I could barely pass as a Scrum Ewok. I had to find a way to confidently describe Scrum and how our company could use it to get better results.

I stressed until I remembered a great part of my CSM class. The instructor asked us to write down any questions, preconceived notions, or concerns on a Post-it and attach them to the wall. Later, if any of the questions or concerns hadn't been addressed, the instructor would read the Post-it and provide clarity. So I decided to use this approach. I called a meeting with my boss, the VP of my department and my colleagues to discuss Scrum.

"Ok," I said, "before we start, write down any questions or concerns you have about Scrum on a Post-it and stick them on this whiteboard." The room grew eerily quiet. After what seemed like an eternity, my boss finally stood up and put a single Post-it on the whiteboard. It said, "What is Scrum?"

This was my first experience with Post-its, and I was already willing to scrap them and Scrum all together. But, I don't give up easily, and I realized that they couldn't have had any concerns or questions, because none of them knew anything about Scrum. It was my job to lead them.

After explaining Scrum, and answering a few questions, the meeting ended. My boss approached me and said, "This sounds great. How do we make sure everyone's following the process?" We determined that I would be my department's ScrumMaster, and that part of my job would involve providing a visual that would help keep everyone on track.

So, I decided to give the Post-it another try. I wanted to provide a compelling, easy way for our team to keep up with our product backlog and track progress. So, after researching various approaches, I decided to get a large dry erase board. I listed all of our projects on the board, and created two columns, Current Sprint and Backlog. That way, every Sprint, our Team could add Post-its for things they were working on, and the PO could add Post-its to the backlog as new items were added.

The Post-it board immediately became a hit. You could say it was our second water cooler. I always find team members discussing new backlog items, or proudly announcing they've completed an item. Better yet, the team has a greater sense of accomplishment, as completed items get sent to a special place, the Wall of Fame, where a mountain of Post-its are proudly displayed (this was initially a molehill).

The Post-it has expanded its influence. Soon after starting our Daily Scrum, we decided to clearly identify the chickens and pigs, by providing "Cluck, I'm a Chicken," and "Oink, I'm a Pig" name tags. All visitors are required to wear a chicken name tag, which usually leads to a discussion about Scrum. Thanks to the name tags, more departments are learning about Scrum and asking more questions about the process.

We also use Post-its to encourage proper lines of communication. Unfortunately, and don't think I haven't tried at least twice, I don't have my own clone to run around and ensure our team is focused like a guided missile on their Sprints. So, everyone's cubes/office door has the "Have a request? Go talk to our ScrumMaster!" Post-it. This again has led to further discussions about Scrum, and we've ensured that all requests are getting properly funneled to the product owner.

So you could say that Scrum has changed the way we do business for the better, but it couldn't have happened without the Post-it (3M, I just sent an e-mail to your PR department. Call me!). These days, the Post-it continues to not only facilitate current processes; it is helping build a foundation for future projects. We just created a Strategy Board, a whiteboard that is separated into two sections, "Where We Want to Be," and "How Do We Get There?" Post-its already cover it.

For those of you thinking If you love Post-its so much, why don't you..., well, I just might do that.

And for those of you who have used the power of the Post-it in your Scrum processes, tell me about it. We're always looking for fun, new ways to better use Scrum.

Scrum In A Nutshel

By Dan Rawsthorne and Douglas E. Shimp

Scrum is about Teams producing Results in an agile way. Scrum Teams achieve results anyway they can by using a simple set of rules to guide effort. We will describe Scrum as a simple applied model so that a central understanding of Scrum can be built. Other complexities of applied Scrum such as scaling, distribution, etc. will be explored elsewhere.

The Team

The fundamental element of Scrum is the Scrum Team (or "Team"), which is a small (usually fewer than ten) group of people that provides useful Results/Products for Stakeholders.

Arguably, the most important role involved in Scrum is the Stakeholder, as the Stakeholders are the ones who have desires, wants, and needs, and are the reason the Team is developing the software in the first place. Often, there is a special Stakeholder called the Business Owner, who actually controls the budget for the Team. The Business Owner is often the one who called or asked the Team to form.

While the Stakeholders are the most important source of validation for the project, the most important person on the Scrum Team is the Product Owner (PO). The Product Owner works with the Stakeholders, represents their interests to the Team, and is the first person held accountable for the Team’s success. The Product Owner must find a result that will satisfy the Stakeholders’ needs and desires. The Product Owner provides direction and goals for the Team, and prioritizes what will be done.

The Scrum Team Members, including the Product Owner, are the people who actually do the work that satisfies the goals and priorities the Product Owner has set for them. The Product Owner must work with the Team to find a rate and direction that the Team can go, to achieve a desirable result. Each Team Member is accountable to the rest of the Team for his/her performance, even as the Product Owner is accountable to the Stakeholders for the Team’s performance. The Scrum Team is cross-functional; that is, people on the Team (collectively) have all the skills necessary to do the work (analysis, design, code, test, documentation, marketing plan, drawings; whatever is required for the desired outcome). The Team is self-organizing, self-managing, and constantly trying to improve; they work on the priorities the Product Owner has set. The Team Members commit to the amount of work they can do without undue influence from the Product Owner.

In order to aid the Team (Product Owner included) in doing its work, there is a role on the Team called the ScrumMaster (SM). The SM's responsibilities are to be a facilitator, moderator, and coach, with particular emphasis on helping the Team mature its self-organization and management. The ScrumMaster manages the relationship between the Product Owner and the rest of the Team, and facilitates removal of impediments for the Team, often working with the Product Owner, the Business Owner, and other Stakeholders to do so. Impediments can come from within the Team and outside the Team. The ScrumMaster understands the Scrum process and how the Team is using it, recommends process improvements, and assures that the Team is following the process they have agreed to. If the Team does not follow its process this becomes an impediment. Most impediments can be addressed by simply causing them to become a center of focus. The SM stimulates that center focus by calling attention to the impediment. Creating a smart center of focus is the art of being a SM.

The Backlog

A Scrum Team's work is managed with a Product Backlog ("Backlog"), which is a prioritized list of Product Backlog Items ("PBIs," "Backlog Items,” or simply "Items"). When the list is small it is just a straight list of things, but as it grows we add grouping mechanisms to organize many little things and help us keep track.

These Items represent the Stakeholder's needs and wants – each of them is a request for something of value from the Scrum Team. These requests can be for anything, including software functionality, marketing, non-functional requirements, technical and infrastructure requests, business support, maintenance of existing systems, and so on. It is a rule of Scrum that the Team shouldn't do anything for any Stakeholder unless it's on the Backlog. The Team will be actively working on the top few Items of the Backlog during the Sprint; this part of the Backlog is called the Sprint Backlog, which is often thought of as a separate list of its own. The Product Owner is responsible for prioritizing that Backlog and thus, creating a distinction between the Sprint Backlog and Product Backlog. From the Team’s perspective, the Product Backlog is work that we might do some day, and the Sprint Backlog is work we are committed to doing.

The Backlog contains Items at all levels of fidelity, from vague wishes/wants/needs to finely detailed requirements. The higher the priority of the Item, the more detailed the request should be, so that it will be ready for planning and execution. Note: “ready” does not imply excessive detail but, instead refers to enough detail. The Team working with the PO will determine what “enough detail” is.

When a Scrum Project starts, the Product Owner should initiate the Backlog by working with the Stakeholders and other Team Members and capturing their needs, wants, and requirements as Backlog Items. As the Project progresses, the Product Owner and the Scrum Team should continuously work with the Stakeholders to (re)prioritize the Backlog, identify new Backlog Items, eliminate noise, and refine and generally clean the items list to get it ready for planning. The project effort will result in product that will often clarify and identify Backlog Items. This process is called Backlog Grooming, and is a continuous process throughout the Project.

Now that we have the notion of the Backlog to work with, let's describe the process, which involves discussion of both Releases and Sprints.

The Release

The goal of a Scrum Team is to produce and release results that meet the goals and priorities that have been set down by the Product Owner (hopefully as a result of working with Stakeholders).

Typically, before a project formally begins, there is a Visioning phase (this could also be the first phase in a project), when the Business Owner, Product Owner, and the Stakeholders produce a Product Vision and a Product Roadmap. The Vision provides the overall focus for the Project, while the Roadmap gives guidance about Releases and their Goals.

The Scrum Team’s purpose is to create a result that satisfies the Stakeholders’ needs, wants and desires, often so that more demand for their services is generated. This production is done through a series of relatively short, fixed-length iterations, called Sprints, in which results are produced by working on Items. The Sprint length can vary, but this requires more discipline on the part of the Team and is not advisable for new, less mature teams. The steps of a Release are relatively simple, and I'll describe them here.

Usually, the first thing that happens in a release is Release Planning. The Stakeholders, the Product Owner, and possibly other members of the Team, get together and negotiate what will be accomplished in the Release. This negotiation considers the Product Vision and Roadmap, balances the needs and wants of the Stakeholders against the abilities of the Scrum Team, and results in a set of Release Goals and a Release

Strategy to achieve them. The Product Owner and Team must update the Backlog so that there are prioritized Items on the Backlog that support the Release Goals and Strategy and are ready for planning.

Once we have a Backlog that supports the Release Goals and Strategy, the Team starts sprinting. The idea is for the Team to do as many Sprints as the Release Strategy calls for, and then Release the Results. Each Sprint looks basically the same, with the Release activities as part of the last one.

The Sprint

The fundamental process flow of Scrum is the Sprint, which is a relatively short period of time in which Backlog Items are converted into Results.

The first thing to do in a Sprint is Sprint Planning. In Sprint Planning the Product Owner works with the Team to negotiate what Backlog Items the Team will commit to for the Sprint in order to support the Release Goals and Strategy. Each of these Items has an agreed-upon definition of "Done," and collectively these Items are called the Team's Sprint Backlog. It is the ScrumMaster’s responsibility to ensure that the Team commits to a realistic amount of work, and that the Product Owner does not unduly influence this commitment. Often, the Items on the Sprint Backlog are tasked out in order to give the Team confidence that it can complete the Item, and thus commit to it. The tasking of Items can help the Team mature by paying attention to the work agreements they make with each other. The tasking can also help the SM detect when the Team is working well.

Once Sprint Planning is over, the Team begins work in the Sprint. The Team self-organizes to do the work and self-manages as it does the work. The Team’s work pattern is described as a swarm to get the job done. Team swarm is a pattern of performing Teams that looks like a swarm to an observer. While the Sprint is in progress, the Team will have Daily Scrums in order that each Team Member understands what the Team's status is. This allows the Team to detect when to adjust in order to be as effective and efficient as possible. These adjustments often take significant time and occur after the Daily Scrum.

During the Daily Scrum, and continuously throughout the day, the Team Members notify the ScrumMaster of any impediments they encounter. It is the ScrumMaster’s responsibility to facilitate the removal of these impediments. Often, this requires working with Team Members, the PO, the Business Owner, and other Stakeholders.

The ScrumMaster must also ensure that the Team does enough Backlog Grooming in order to be prepared for the next Sprint's planning meeting. The Backlog Grooming is a strategy to prepare enough work to begin next so that a rhythmic flow of work can happen.

When the Sprint is over there is a Sprint Review, when the Product Owner and the Team show the Team's Results to their Stakeholders. This is done for two reasons: to prove to the Stakeholders that the Team is moving in the right direction, and so the Team can get feedback on what they've done. If necessary, the Release Goals, Release Strategy, and Backlog are updated as part of the Review (or soon thereafter), considering the Review and any "business reality" changes the Stakeholders may have. When Teams are small they can rely on more intuitive reasoning to determine what the "right direction" is. As a Team grows they will see a need for more sophisticated techniques that use metrics to help them answer what the "right direction" is.

After the Sprint Review, the Team has an internal retrospective to analyze its performance and process. The Team decides what changes, if any, they wish to make to their process as a result of this analysis. These changes will be "enforced" by the ScrumMaster in future Sprints. To enforce something the SM will need to shift the focus to the issue at hand and then let the Team react. Telling the Team what to do is not desirable. Shifting the Team focus and thereby enforcing change is an art of the SM.

At this point the Sprint is complete, and the Team either begins the next Sprint, the next Release, the next Project, or disbands, as appropriate.

Quick Summary

Team of 7±2 does the work
PO provides the work requests
SM provides care for the whole team (PO/Team)
Team swarms on the work
Team is cross-functional
Team owns its process
PO provides validation for each work request
Work is done in short bursts < 30 days each (Sprints)
Work starts and stops with Planning and Review
Review demo for product; Review retro for process
Daily Scrum detects any adjustments needed
PO determines priority as a flow of work requests
SM observes and helps the whole team adjust
SM tunes the whole team for maximum performance

ScrumBut: Construct the Sprint Backlog According to Individual Specialist Capacity.

By Raymond Shanley

I was recently discussing Scrum with some Scrum Teams, and one team was convinced that a certain ScrumBut was a better way to do things. This particular real life ScrumBut is to construct the Sprint Backlog so it has just the right amount of work for each specialist in the team based on how many story points each individual can deliver in a Sprint. Trying to argue that this approach is against the Scrum rules is not enough to convince people not to use it. At the time of the discussion I was unable to convincingly express why the approach is counter-productive. Afterwards I thought it must be that the problems caused by the approach are not immediately obvious. So I decided to run through an example on paper, which I will now present.

The product concerned is already a few years old and individual specialists have been responsible for parts of the product over those years. The team changed over to a Scrum approach in the past year. So due to the historical situation it is true that a specialist can finish an item in his or her component quicker than someone else. In order to change this situation, learning and knowledge creation would be necessary.

Before we continue let’s summarize the normal Scrum approach. The Team gives estimates for each item in the Product Backlog. The Product Owner then prioritizes the items according to value (and other factors can also be considered such as risk and dependencies between items). The Product Owner is responsible for generating highest value for the stakeholders in a sustainable way and generally wants to finish the highest value items first. The Team is responsible for figuring out how to deliver the items. There is a clear separation of responsibilities between Product Owner and Team. If there are specialists in the Team, the prioritization occurs independently of how much work these specialists are capable of handling in a Sprint.

Ken Schwaber gave ScrumButs a particular syntax: (ScrumBut)(Reason)(Workaround). So here is a formulation of the ScrumBut in this article using the standard syntax: "We use Scrum, but (we want individuals in the team to have just the right amount of work in his/her area of expertise) (so we construct the Sprint backlog according to individual specialist capacity)".

I will run through a concrete example for 4 Sprints first using the ScrumBut approach mentioned above and then using the normal Scrum approach. This is a simple example. It would be possible to construct a more complex example but the same basic problems would emerge so let’s keep it simple. In this example I assume that the Product Backlog prioritization does not change between sprints. If prioritization changes (like in the real world) the problems discussed here are at best only masked slightly.

Let's say we have 5 components in this particular product being developed by the Team. Each component is developed by 1 specialist and each specialist is capable of producing a slightly different amount of work per Sprint as in the following table. The team velocity is calculated as the sum of the individual velocities.

Now let's say our initial product backlog looks as follows. The letter represents the main component affected by a given story. I generated the order of the backlog by writing a list of the letters on a sheet of paper as randomly as possible. Then I wrote story points beside the letters also as randomly as possible (values between 1 and 3).

Summary of the stories on the Product Backlog so far:

ScrumBut Approach, Sprint 1:

If we now go through the Product Backlog and construct the 1st Sprint Backlog according to how much work each specialist can take on we get the following:

So the items that fit in the sprint are 1, 2, 3, 4, 5, 7, and 8, which gives a total 13 story points. Estimated velocity was 17. Item 6 did not fit in because developer C (the developer of component X) was already fully loaded. If specialists have spare time they can either do some other task outside the product scope or take on an item in their specialization lower down on the Product Backlog.

ScrumBut Approach, Sprint 2:

Summary of new items that entered the Product Backlog before the Sprint 2 Planning Meeting:

Below is the Product Backlog for Sprint 2, showing old items and the new items that were added before the Sprint 2 Planning Meeting. The last column shows whether the story made it into the Sprint Backlog or not (as usual, calculated based on individual developer capacity).

Note that item 6 is too big to be done by developer C in one Sprint. This could possibly be split into smaller stories. However, splitting it still does not alleviate the basic problem that developer C appears to have too much work, which creates a bottleneck in the system.

Note the pattern starting to appear, which is that higher priority items are being replaced by lower priority items in the Sprint.

The items that fit in this Sprint are 9, 10, 11, 12, 13, 15, 16, 17, and 20, which gives a total 14 story points.

ScrumBut Approach, Sprint 3:

Summary of new items that entered the Product Backlog before the Sprint 3 Planning Meeting:

Just as for the previous Sprint, here is the state of the Product Backlog. The final column shows whether the story made it into the Sprint Backlog (again, based on individual developer capacity).

The items which made it into the Sprint are 14, 19, 21, 23, 25, 28, 29, and 30, which gives a total of 13 story points. In this Sprint it is becoming clear that prioritization is hit-and-miss. Roughly every 2nd item needs to be replaced by a lower priority item.

Also, component X is clearly a bottleneck. At this point it might be possible to intervene and say developer C needs help and ask someone else to learn X. However, there are at least two disadvantages to this. First, it is a reactive rather than a proactive approach. It is at a late stage that developer C is getting help and he/she has so much work to do it will not be easy for him/her to take the time to show someone else the ropes. Secondly, this monitoring of potential bottlenecks requires additional administrative overhead. Someone needs to be constantly keeping an eye out for the problem occurring. With the normal Scrum approach you get this balancing automatically.

ScrumBut Approach, Sprint 4:

Summary of new items that entered the Product Backlog before the Sprint 4 Planning Meeting:

Same as for the previous Sprint here is the state of the Product Backlog. The final column shows whether the story made it into the Sprint Backlog (based on individual developer capacity).

The items which made it into the Sprint are 18, 24, 31, 33, 34, 35, and 36, which gives a total of 12 story points. In this Sprint more items were taken from the bottom half of the backlog than from the top half.

Scrum Approach, Sprint 1

Now let’s walk through the same example with the normal Scrum approach so we can compare the results.

The estimated velocity of the team is 17 but let’s just take on 14 story points to provide for cross learning. The top 7 highest priority items make it into the Sprint.

Scrum Approach, Sprint 2

This time we also take on only 14 points to allow for cross learning. The top 8 stories make it into the Sprint.

Scrum Approach, Sprint 3

This time let’s take on 16 out of an estimated 17 velocity as less cross learning is necessary as time goes on. In this Sprint the top 9 items are taken into the Sprint.

Scrum Approach, Sprint 4

For the final Sprint in this example let’s take on 16 out of an estimated 17 velocity. In this Sprint the top 9 items are taken into the Sprint.

Let's compare the items remaining in the Product Backlog at the beginning of Sprint 4 of each approach:

Conclusion

The example described in this article demonstrates that dangerous bottlenecks can develop if using the given ScrumBut approach. It also demonstrates that the ability to prioritize properly is diminished by the same approach. These are not the only problems caused. Other problems include:

• The so-called team is operating more as a collection of individuals. There may be no common sense of responsibility.
• One-piece flow may be affected. Parts of stories may be finished at the end of a Sprint and other parts missing.  
• The team has no redundancy built in, which means if someone goes on vacation or gets sick there is a problem.  
• Self-organization is effectively being killed. The team does not have a chance to decide itself the best way to deliver the functionality for a Sprint. This may also lead to motivation problems (intrinsic vs. extrinsic motivation).  
• There may be an issue with trust: Does the Product Owner trust the team to deliver on a Sprint?

My advice is to avoid this ScrumBut even if it leads to reduced productivity (perceived or not) in the short term. Keeping this ScrumBut will lead to more serious problems in the long term.

9 Tips for Creating a Good Sprint Backlog

By Luciano Félix

The sprint backlog is a simple list of the tasks that must executed by the team in order to deliver an increment of functional software at the end of that sprint. Sprint backlog creation happens in the second part of the sprint planning meeting with the participation of every team member. Giving some real attention to this process is fundamental to a better understanding by the team about what should be done and to better planning during the sprint. Despite this, many teams still struggle with this activity. I hope these tips will help.

1. Involve every team member in the process. It can’t be said enough: the involvement of every team member in the process of sprint backlog discovery is essential. On a multi-disciplinary team, everyone can contribute to task creation, enabling the team to draw from several different perspectives about the story. This generates a much richer Sprint Backlog than if only coders or a technical guru were involved.
2. Discuss how every item should be implemented. Before any tasks are written on post-its it's necessary for the team to spend some time discussing every story that will be brought into the sprint. In fact, the majority of the meeting should be dedicated to understanding how the team is going to tackle the stories. This discussion will involve creating basic designs, checking existing code, discussing architectural possibilities, and so on. Having a shared understanding about the story and the possible solutions will enable the team to create a task list that truly expresses the work to be done.
3. Have a definition of done. Having a common definition of done in place, available and visible to everyone is extremely important. This definition will serve as a guide to what should be done and will remind the team what the general acceptance criteria are for every item in the backlog.
4. Identify all kinds of tasks. Too many teams focus on coding tasks. The truth is, though, that coding is not enough to deliver real working software. The sprint backlog should include every kind of task: object modeling, coding, learning a new technology, database activities, tests, and so on. Having a posted definition of done will help to remind teams of the tasks they are forgetting. By listing every aspect of delivering working software and going through those tasks, the team will gain a new understanding of the real effort the next sprint will require.
5. Don't estimate tasks at all. This is a sensitive one. Estimating tasks in hours is popular and may be necessary when a team if first starting out. In the end, though, we can drop this without losing much. (See Alan Atlas’ article about this topic) The team commitment to the sprint should be done with the backlog items in mind, not the tasks. After all, if we estimate that a task will take 4 hours but it actually takes 12 hours, as long as the team achieves the sprint goal, what difference does it make? Identifying as many tasks as possible and creating a sense of constant progress during the sprint should be enough.
6. Don't assign tasks up front. Resist the temptation to direct work; the team should decide who is going to do what according to the circumstances. If you start to assign tasks to the “most suitable” team member, it will prevent the rest of the team from learning new things, block communication, and decrease collaboration. Empower and trust the team to manage themselves.
7. Review the sprint commitment. After task identification, when the team has a much better understanding about the real effort that is needed, the sprint commitment should be reanalyzed. Does the selected sprint backlog really fit in the sprint? If not, there are some alternatives. Drop the item with the lowest priority or split stories into smaller pieces. What matters in the end is that the team can commit to something they have a good understanding about.
8. Don't use too much time. Respect the time box. Define a meeting duration and stick to it. Timeboxing forces the team to concentrate and intensively discuss the items, making it much more likely that the tasks will be uncovered. The team cannot always identify everything that should be done during the sprint, but that's not a problem. It is much more important for them to gain a thorough understanding of the stories they are bringing into the sprint.
9. Evolve the Sprint Backlog during the sprint. The team will understand more about the stories as they work on them. New ideas may arise and old ideas may be dropped. The Sprint Backlog should reflect these changes. The Daily Scrum is an excellent time to create new tasks and lose unnecessary ones.

If the team invests the time and effort to build a good sprint backlog it will be rewarded with a much better overall understanding of the work to be done, a sense of progress on a daily basis, and a clear commitment to what will be delivered. It may not be easy, but it will be worth all the hard work.

The Case of the Time Tyrant

By Alan Atlas

Managing a Scrum team for the first time brings some unexpected challenges. Often, at least at our company, the lucky manager hasn’t received the same Scrum training as the ScrumMaster or the team. She hears a lot of vague things about letting the team manage itself, but doesn’t quite know what to expect, let alone how to properly manage a Scrum team. All she really knows is that she is responsible for the success of a team over which she has very little control and who are using a process she doesn’t really understand.

As the scrum process takes hold, it begins to do what we promise in training: it makes a lot of things visible that were not visible before. One common example of this phenomenon is the fine-grained list of tasks that the team is doing on a daily basis (the sprint backlog). Estimates for these tasks in ideal hours are a tantalizing target for managers who are used to creating success by actively controlling (managing) their people. These lists are often like candy to managers who have never before had such visibility into what their teams are doing on a daily basis. They latch onto this concrete artifact with its numbers and lists and immediately start to manage with it.

Many hard-charging managers become puzzled, scratching their heads in confusion and consternation as they try to apply waterfall-based thinking to the sprint backlog. They end up wondering how it is that they can’t make the estimated hours add up to the number of hours that the team has available during the sprint, even allowing for overhead. Worse, they start to wonder why the team appears to be committing to work that adds up to a paltry 30 percent or 40 percent of the total time available during the sprint.

“Five people for 30 days (22 work days) adds up to 110 possible person-days of work! That’s 880 hours! I only see 350 hours estimated on your backlog! This can’t be right. You’re being lazy or inefficient. This Scrum process is awful, and I’m going to get very involved to make sure we’re doing the right amount of work!”

This is something that I see fairly often as Scrum spreads throughout my large, successful Internet company. Does this happen at your company, too?
What is the thought process that got our new-to-agile manager so upset?

• Employees need to be supervised (command and control).
• Time spent is a good measure of work done because employees have already been told the correct thing to do.
• 100-percent-resource- (employee-) utilization is the goal in order to avoid “waste” and reduce costs.
• If utilization is low, it is because employees are not being controlled enough. They are getting away with being lazy.
• Therefore, I as a manager must make sure the team is spending every possible minute doing work. That’s the way to get the most software released!

By contrast, what would an experienced agile manager be thinking?

• The team is doing the most work possible in the time allowed.
• The team is concentrating on delivering value, defined by product backlog items, in priority order.
• The most useful measurement of team accomplishment is the delivery of product backlog items as working software, so that is what should be monitored. Time spent does not correlate with delivering value.
• Improving the team’s velocity requires removing organizational impediments that are revealed by Scrum (e.g., high operations load, high maintenance load, technical debt in legacy software, requirements churn and lack of definition, no continuous integration environment, poor employee retention, incorrect team size, incorrect people on the team).
• The goal of Scrum is not to achieve the highest resource utilization; it is to achieve the highest throughput of completed, deliverable value. Little’s Law, Goldratt’s Theory of Constraints, and the Lean principles of pull scheduling and working to capacity explain why Scrum can deliver on this goal. From these underlying principles, we realize that 100 percent utilization actually works against high productivity.
• I, as manager, care that the team produces the most value possible each sprint, therefore the best way for me to reinforce the team’s focus on improving velocity is by helping to remove impediments.

We already know what 100-percent-utilization of roads gives us: zero throughput (gridlock)! Why do we think it is different for a development team?
Concentrating on resource utilization sends a negative message to the team without improving anything except, well, resource utilization. It diverts energy and focus from the important thing, which is delivering value for customers. It takes away the single largest source of productivity we have available: the creativity and commitment of the team.
So what should our manager, who is perplexed because “the hours don’t add up” and suspicious that not enough work is getting done, do? The key is to stop thinking in terms of people spending more time doing more work and start thinking in terms of changing the tasks that the team is doing so that the time spent working contributes to value and not waste. This shift in mindset leads to a different set of possible actions for the manager:

• Concentrate on velocity as defined in Scrum: the amount of value completed each sprint. Watch for the velocity to increase every few sprints as a result of the improvements that you and the team make.
• Stop worrying about why the hours don’t add up. Start noticing instead that the team produces the working software they say they will at the end of every sprint.
• Challenge and inspire the team to improve velocity by changing the things that get in the way of building lots of good software. Ask about the impediments that have been raised in retrospectives and what has been done to remove them.
• Work with the team to address organizational impediments as they are identified in retrospectives.  For example:
  • Do you really need to have a meeting of the entire organization every week?
  • Is the corporate QA group able to support your team in the most efficient way possible?
  • Are outsiders randomizing your team by redirecting them during the sprint?
• Let the team self-organize to improve velocity. Ask them what changes they are making that will enable them to spend more time building software and less time doing unproductive work. For example:
  • Did people spend a lot of time fixing broken builds that could have been spent delivering features?
  • Were team members available to help one another when help was needed?
  • Did the team swarm to complete features quickly, or to overcome difficult obstacles?
  • Did people privately wrestle with problems rather than reaching out for help? Look for and review impediment backlogs.

Thinking in agile terms will lead the manager, and the team, to their shared goal of shipping the most, and highest value, software possible. The improvements to velocity that are achieved in this manner will be long lasting and sustainable.

The passage of time, in and of itself, signifies nothing. Don’t tyrannize your team with ideal hours. Time is enough of a tyrant as it is.

Writing the Product Backlog Just Enough and Just In Time

By Mike Cohn

Some people want to take the stance that no work should be done in advance of the sprint. That is clearly untenable. To see why, let’s take that view to its extreme: If we did nothing in advance to understand what we're building, we’d show up at the planning meeting and say, “Hey, what should we build this sprint? We were working on an eCommerce site yesterday, but I think maybe we should switch to writing a word processor...” The team would literally have nothing written down—no product backlog / user stories / prioritized feature list at all.

This approach leads to what I call “billiard ball sprints.” Without any planning, the team starts a new sprint on the day after the prior one end, but spends the first two to five days “getting ready” to start the sprint. The start date of the second sprint is knocked forward by the end of the first—like one billiard ball knocking into another.

Having dispensed with the possibility that no work should be done in advance we are left to consider the question of how much work should be done in advance. Many say that as little as possible should be done: the team should do no more than write a few words of a user story on an index card to represent each product backlog item. While it’s true that this may be sufficient in many cases, it would clearly not be adequate in all situations.

My view is that each product backlog item (usually reflected as a user story by teams I train or coach) should be captured just in time and in just-enough detail for the team to go from product backlog item to working, tested feature within a sprint. To see why just-in-time and just-enough are appropriate targets, suppose we decide to write a checkbook program to compete with Intuit's Quicken product. We create an initial product backlog that includes these two user stories:

• As a user I can see the current version, company website, and copyright in a "help about" dialog so that I know useful information about the product.
• As a user I can enter a check in my register so that I can track who I pay.

That first story can go from that short description to implemented code quite easily within a sprint. The analyst will have time to figure out exactly what the text should say; the user experience designer (UED) will have time to mock up two or three screens, show them to some users, get feedback, and create the best possible “help about” screen. And the programmers will have time to code it and the testers to test it. In short, it meets the just-enough-detail criteria.

The second user story, “As a user I can enter a check in my register,” is too big to be done in a single sprint. It encompasses the entire main user interface (UI) metaphor—will our system look like a paper check register? How many rows in the register? How will users choose things like check numbers or electronic funds transfer (EFT) transactions, and so on. There is no way the UEDs can figure all that out in a two-week sprint. This user story is not explained in just-enough detail. This is where our second attribute comes in: detail should be added to this user story (product backlog item) just in time. If the team will not work on this user story for six months there is no need to expand on what is already written. On the other hand, if the team hopes to start it in a few sprints, it is likely time for the UEDs to figure out the answers to the high-level questions listed above.

To do this, they’ll need to allow time to “figure out the answers” in the upcoming sprints. Let’s say that during the first sprint the team chooses to work on the “help about” story and likely a few others (not shown in our sample product backlog above). They also agree to spend some time figuring out what the main UI metaphor for the system will be.  During this time the UED may design a couple of screens and show them to a few dozen or hundred users, get feedback, and do it again. This may happen a few times. When they finish they may have turned that one user story (as a user I can enter a check in my register) into a dozen smaller stories, perhaps specifying what fields are needed and other details such as:

• As a user, when I enter a new check it defaults to the last check number + 1
• As a user, I can enter a memo for each check, etc.
• As a user, I can double-click on a check in a list and see the current item look like a paper check.

In some cases splitting a large story into smaller ones is sufficient to show the new items at the right (just-enough) level of detail. When it’s not, we can augment the user story with additional information. I like to write user stories on index cards. That was sufficient for the "help about" story. It’s not for the initial large user story encompassing our system’s main UI metaphor. If splitting a story does not add just-enough detail, the UED and others involved may want to staple a UI design spec to the index card. (If you are using a software system for managing your product backlog, your virtual staple may be a hyperlink to a wiki page.)

The UI design spec that is stapled to the user story card will not yet be perfect; rather it will be close enough that remaining details can be figured out during the sprint. For example, the UED may not yet have decided if each check should take two rows or three on the screen and wants to do a bit of user testing early in the sprint while the team codes that story. He'll get them an answer early enough that they can do it either way during the sprint. 

The goal of the UED (and anyone else involved at the time) is to add detail to the story in a just-in-time manner. There is usually no value to splitting a large user story up now or stapling a document to it if we won’t work on that product backlog item for quite awhile. While working to add detail in a just-in-time manner, those doing so should strive to add just-enough detail that no individual item will take more than one sprint to complete. Just-in-time and just-enough become the targets for establishing a smooth flow from product backlog to sprint backlog.

The Why of Scrum

By Chris Fry

Scrum is built on a few simple principles:

Communicate. Sharing information creates visibility, better decision making, and a common understanding of shared goals.
Empower the team. Nothing is more powerful than a team that is in control of its own destiny--a team that thinks the only thing limiting what they can accomplish is how creative they are and how hard they work.
Learn and improve. Learning is about trying something, looking at the results, and then improving.
Deliver value early. Build trust with people by prioritizing work, committing to deliverables, and delivering them reliably. This builds trust with coworkers, other teams, and customers.

Scrum turns these principles into practice using the following mechanics and roles:

Communicate

• Communicate daily about your progress (daily meeting).
• Track your work as a team so you can make informed decisions about achieving your goals (sprint backlog).
• Work as a unit and don't let one functional area swamp another. (Stay in sync.)

Empower the team

• Give teams the power to control their own destiny and deliver on goals (sprint goals).
• Get impediments out of their way (ScrumMaster).

Deliver value early

• A prioritized list of work, organized and prioritized from a customer perspective (product backlog, Product Owner).
• Plan your work as a group, work on it in priority order, and set goals for an iteration (sprint planning meeting).
• Commit to your team members about progress (sprint tasks).
• Work in sync with the group and maximize for the team's efficiency (get to done, work as a team, don't impact other teams).
• Don’t degrade the system, always be within days of shipping the product (not weeks or months). (Don't create debt.)
• Work on relatively equally-sized tasks that can move efficiently through the system (grooming the backlog).

Learn and improve

• Work in short sprints and measure progress (sprints).
• Demonstrate your work at the end of the iteration and collect feedback from a broad set of people (sprint review).
• Reflect after every iteration on how you can get better at meeting your commitments and produce more code (sprint retrospective).

Scrum works best when its mechanics (sprints, daily meetings, grooming the backlog, etc.) are clearly tied to their driving principles (communicate, empower the team, deliver value early, learn and improve).