Planning Poker

Teams often ask “what if we estimate wrong”. To me this is reality for any estimation process. By definition we are “guessing” (hopefully educated) and therefore our estimates will be wrong. The idea is to be consistent rather than precisely wrong. This allows teams to better predict based upon similar constraints to earlier iteration how much they will be able to deliver in the next iteration. Rather than basing estimates on predictions of the future we are basing them on what we have done in the past.

The use of “estimate size; derive duration” method of estimation helps teams gain knowledge about how much they can deliver in a time-boxed iteration. One technique to generate the estimates of size is Planning Poker. Most teams start out attempting to get the estimate exactly “right”. I will not advocate that this is bad to do but I do think that teams would find Planning Poker and other exercises for estimating size more valuable if they focused on the communication that occurs. The real magic of Planning Poker is that cross-functional team members and team members with different perspectives are able to share their knowledge with each other and ultimately meld the points of view into an approach for implementing a user story. A focus on communication allows teams to capture important information, constraints, and decisions around a particular user story and better understand as a team what is involved in its delivery.

Sprint Planning Task Breakdown

When teams come together for the first time in organizations where they have been separated by functional role or even teams that haven’t worked together before, the act of breaking down user stories into tasks assists teams with communication. If the Product Backlog describes the “what” then the Sprint Backlog describes the “how”. Tasks are tools for capturing the “how” and makes it visible to the entire team. Instead of team members with different functional roles, team members describe how they will contribute to the potentially shippable product increment delivered by the end of the iteration. Instead of focusing on the perfect tasks and estimates on those tasks, I believe it is more valuable to have a shared understanding of how the team will deliver the user story. Tasks are just the tool to make visible that shared understanding and we should focus on the communication between team members and capturing the important details that enable successful delivery.

Now, tasks are not the only way to get a shared understanding, of course. I have been on teams where we would talk, draw a little picture on a post-it note, and then agree with as a team that was enough to plan with. This was with an extremely experienced Scrum team that worked together or around each other for a long time. When a new team comes together in an organization that has not created user stories before they have difficulty getting “right-sized” user stories for the team. Most of the time there seems to be some difficulty breaking them down items into small enough items for the team to deliver within 1/2 of a sprint’s length. As the team does task breakdown they are better able to capture details that help them work out how the whole team will contribute to the user story. This leads to recognition of user stories that are too big or even those that are ambiguous.

New teams using task breakdown in their Sprint Planning meetings should focus on how they communicate with each other and make sure that each member of the team is heard. This will lead to a better shared understanding of how they will work together and deliver successfully.

Focus on Team Communication

Here are some things that teams can do to help their communication in planning:

• Make sure all team members are heard so they will feel compelled to participate
• Always discuss reasons why you, as a team member, are not satisfied with the plan
• Don’t push your estimate or task breakdown suggestions on the entire team
• Cross-pollinate within your team across functional role boundaries to better understand other roles
• Use past experiences and story-telling to describe reasons for a particular position
• Use whiteboards and design techniques to visually portray ideas

Hopefully a focus on team communication will help make estimating and task breakdown a more valuable experience for your team. Please share things that your teams have done to help focus more on communication to increase shared understanding by leaving comments on this blog entry. I look forward to hearing from you.

• Technical debt: tends to focused on the code and reveals itself in duplication and code smells
• Quality debt: focuses on QA aspects of software development and shows up in growing bug databases and longer regression test runs
• Configuration Management debt: focuses on integration and release management aspects and becomes apparent with extreme branching and inability to recreate environments from scratch
• Design debt: focuses on design constructs of components within an application or enterprise infrastructure and is usually difficult to figure out until you are close to a deadline such handling production load
• Platform Experience debt: focuses on the people in the software creation process and usually involves extreme specialization and waiting on people to finish their part

Without further ado, here are the slides:

Also, here is the picture I use to discuss Managing Software Debt from high level in terms of maintaining and enhancing value of software assets:

A healthy Product Backlog contains not only new features but also technical requirements to support the next Product Backlog items in priority. The development team is expected to review the Product Backlog frequently to provide cost estimates for Product Backlog items to help the Product Owner prioritize based on both cost and benefit. During the development team’s review they will suggest Product Backlog items that are missing from a technical point of view in the product definition. These technical Product Backlog items will be discussed with the Product Owner so they are able to prioritize them effectively. It is essential that the development team explain why each technical Product Backlog item is important to support other upcoming items. If this is not expressed the Product Owner could be inclined to demote those technical Product Backlog items because the value of them is not understood enough.

When issues are found in the software they usually come in three varieties:

• Enhancement – a suggestion for improving the current state of the software from a user’s point of view
• Defect – a system fault that occurs while using the software
• Fire – a system fault that is inhibiting significant usage scenarios in the software and must be fixed immediately

Enhancements are requests for improvements to the software based on the perspective of the user. These improvements should be prioritized based on their value against all other Product Backlog items. An enhancement and defect issues are hard to distinguish from one another at times but that is fine. Defects are system faults that users are able to workaround but should not be happening from a user experience and/or technical perspective. Since we are able to work around these defects and the development team is able to provide a fix in the next iteration they are placed into the Product Backlog and prioritized against all other Product Backlog items. Fires are defects that cannot be worked around and cause serious problems for users of the software. In healthy software applications, fires should be a rare occurrence. It is important that a fix is implemented right away and may interrupt the work getting done in the current iteration.

Figure: This flow diagram describes how an identified issue is triaged in an iterative and incremental approach such as Scrum. If the issue is an enhancement or defect that can be worked around for now it goes into the Product Backlog and prioritized based on its value. If the issue is a “fire” or defect that cannot be worked around then it must be fixed immediately. The development will put the fire into their current list of work in the Sprint Backlog and figure out how it effects their commitment to deliver on their current iteration.

Defects are captured in bug databases in many organizations. Teams using the Scrum process to manage their software development find themsves in a predicament. Do we continue working from two lists, the Product Backlog of desired features and bug database? Or do we incorporate items from the bug database into the Product Backlog? I suggest all teams should incorporate defects into the Product Backlog. There are multiple reasons to do this:

• Development team does not make priority decisions for the business stakeholders. If the development team decides to work on defects rather than desired features then they are deciding the defects are higher priority than the desired features without including the Product Owner in the decision-making process.
• Minimizes the amount of hidden work done by the development team. By providing visibility into the defects, the development team is being transparent about the state of the software they are working on.
• Provides the Product Owner with an opportunity to prioritize the defect lower. The Product Owner could decide the defect is not important enough to fix at this time.
• Allows development team and Product Owner to design a solution for dealing with defects. From time to time the defect provides insight into a design flaw that the Product Owner would like to improve.

Ultimately, the development is able to maintain alignment with business priorities for the software. Priorities are decided based upon the full reality of the software, new features and defects included.

A single work queue, such as the Product Backlog, provides visibility to the development team about current expectations about upcoming work. The Product Owner should share the Product Backlog with the development team and discuss the direction of the product beyond the next iteration. As the development team gains knowledge about the direction of the product they will be able to provide input into the Product Backlog. This visibility is important so Product Backlog items do not surprise the development team when it is too late to prepare a proper solution.

AgilePalooza is a one day Agile conference on Friday May 29th at the San Francisco State University downtown campus. There will be two tracks: Learning Agility and Advancing Agility.

“Learning Agility” will be presentation style whereas “Advancing Agility” will use the open space format.

Speakers include David Hussman (DevJam), Chris Sterling (SolutionsIQ), Luke Hohmann (Enthiosys), Lee Henson (VersionOne Services) with special guests Ainsley Nies (open space co-facilitator) and Ian Culling (VersionOne CTO). When not presenting for the “Learning Agility” track speakers will participate in the open space.

Space is limited and the cost is low so please register soon if you would like to attend. For more information or to register please visit www.AgilePalooza.com.

Where?

San Francisco State University Downtown Campus, 835 Market Street, San Francisco. (Powell street BART station in the Westfield Center) – Map/Directions

When?

9am-5pm (check-in and continental breakfast starts at 8am)

Cost?

$69

Register here: www.AgilePalooza.com

ISO 9126-1 Software Quality Attributes

Before I knew about this standard I would discuss how different quality attributes are in conflict with each other. For instance, if we write code that is focused on performance we lose some maintainability. It will be more difficult to read code focused on performance because readability will be sacrificed to some extent.

Now that I’ve known about ISO 9126 for many years, I made a simple spreadsheet tool to interview Product Owners, stakeholders, and software development team members with. Here is the Excel spreadsheet form of this tool:

Software Quality Attributes Rating Tool

Although a bunch of smart people have come up with ISO 9126, I found that modifying the software quality attributes rated in the tool worked more effectively with interviewees. This tool is not to decide what software attributes will be present in the software product getting developed. It is used to identify which software quality factors the team should put more emphasis on when making trade-off decisions during the project. Here is a list of the software quality attributes used in the tool:

• Suitability – Functionality is suitable to all end users
• Interoperability – Functionality interoperates with other systems easily
• Compliance – Functionality is compliant with applicable regulatory guidelines
• Security – System is secure: confidentiality, integrity, availability, accountability and assurance
• Maturity – System components are proven stable by others
• Fault Tolerance – System continues operating properly in the event of failure by one or more of its components
• Recoverability – System recovers from failures in surrounding environment
• Understandability – Able to use system with little training
• Learnability – Supports learning of system functionality with little external interfacing
• Operability – Ability to keep a system in a functioning and operating condition
• Performance – Perceived response is immediate
• Scalability – Able to handle increased usage on the appropriate amount of resources
• Analyzability – Ability to figure out how the system functions
• Changeability – Ability to change the system components to meet new business needs
• Testability – Ability to create repeatable and specific tests of the system and potential for some to be automated
• Adaptability – Ability to change out system component functionality quickly
• Installability – Ease of installation and reinstallation
• Conformance – Conformance to industry and operational standards
• Replaceability – Ability to replace system in the future

Using the tool is quite simple:

1. Emphasis Ranking: Have the Product Owner score each of the software quality factors from 1-5 (1 being less applicable and 5 being more applicable) in terms of the software product.
2. Business Stakeholders identify 3 Must Haves – Ask the business stakeholders what are the 3 software quality factors they want most and stack rank them from 1 to 3
3. Software Development Team 3 Must Haves – Ask the software development team what are the 3 software quality factors they want most and stack rank them from 1 to 3
4. Capture Notes about Decisions – Use the notes column to capture any specific decisions about the software quality factors that would help the entire software product team come to consensus.
5. Discuss Must Haves across Groups – Get the Product Owner, business stakeholders, and software development team members together to discuss and come to consensus on which software quality attributes they will focus on for this project.

Please let me know how you use this tool. There have been many teams that have taken up this tool and found it to be helpful for communicating what is most important from a software quality attibutes point of view in the project. Hope it does the same for you.

• We are going to implement the Scrum methodology.
• We’re doing a modified Scrum.
• Our developers are using a Scrum process.

These may seem like innocuous statements but they are indicators of potential misinterpretation of how Scrum is best utilized. Scrum is not a full development process (although almost anything that has steps could be considered a ‘process’) and it is not a methodology. It does not tell you how to implement the software. It is a simple-looking framework that will help a group developing products figure out what is not working well so they can fix it. Here is the Scrum framework diagram:

The Scrum Framework

At first, people and teams implementing Scrum focus on the process without understanding why and how to do each piece effectively. We believe that we will be “doing Scrum”, and will gain all of its benefits, by just:

• Keeping a list of work (the Product Backlog)
• Assigning it to the team during a Sprint Planning meeting
• Doing that work over the course of the Sprint

This focus on going through the steps can be dangerous and frustrating for individuals, teams, and managers. Scrum is NOT A SILVER BULLET! No process, practices, or techniques are. Instead of focusing on the process, practices, and techniques of Scrum, I suggest individuals, teams, and management focus on the learning that can be produced by a team doing Scrum and act on that learning.

Scrum is an Empirical Process Control. The idea is that you plan and then do something, inspect what you did, and then adapt your behavior to improve on what you did. It is a learning framework for product development teams. This learning cycle is referred to as “inspect and adapt”. All 3 Scrum roles are involved in the learning: the Product Owner, ScrumMaster, and Developers (when I say developers I mean anybody needed to build the product, not just coders). In Scrum, there are 3 specific “inspect and adapt” cycles:

• The Daily Scrum meeting allows the team to focus on their commitment for the current Sprint and whether they are still on track to deliver on that commitment. If they are not able to meet the commitment then they are asked to adjust the Sprint, thereby adapting to the situation.
• The Sprint Review meeting allows customers to view a potentially shippable product increment created by the Team and provide feedback that adjusts the Product Backlog contents and priorities. We are inspecting the product and adapting to a new understanding of the product.
• The Sprint Retrospective enables the Team to improve the process they use to delivery software each Sprint. The Team is expected to inspect their process honestly and thoroughly to figure out how they can adjust for improved delivery capability in the following Sprint.

If you read my blog often, you might recognize this from a previous post called “A Kaizen Mindset” that has good information on how to use learnings and manage the impediments around those learnings.

Scrum is more of a tool than a methodology. It will make visible what is not going as well as it could be.  It is then up to people in the team and organization to make changes to improve it. With each incremental improvement the product development team will move that much more effectively on its work. Rather than focusing on getting perfect at the steps in the Scrum framework, find out what can be improved in your delivery process and adapt it accordingly. If a part of the Scrum framework is difficult to do or seems like a waste then instead of eliminating that part, find out why it is difficult or wasteful in its adoption. There is usually a hidden impediment behind these difficulties and perceptions that if eliminated will allow the product development team to be more effective.

Scrum is not a destination. It is rather a tool that a product development team uses to continually inspect and adapt their way to more effective delivery. The destination should be your business and development team effectiveness goals. How can we deliver more product? How can we reduce time from inception of project to release? How can we release more often at a lower cost for release stabilization of the product? How can we reduce the risk in our project delivery and portfolio? The destination should be substantial and worthwhile. Scrum is just the vehicle to help get you there.

function of (sprint length, team makeup, sizing nomenclature, product)

Given these parameters to team velocity, how can each affect team velocity when modified?

Sprint Length

It is common for teams when they first implement Scrum to have difficulty with short sprint length. They are probably not used to delivering potentially shippable code every 2 weeks or whatever their initial sprint length is. When a team is having difficulties many of them believe that lengthening the sprint length will alleviate the problems. When a team is thinking about doing this, I now share a phrase that I heard from Chet Hendrickson at a technical debt workshop we both attended:

Lower the threshold of pain

Instead of changing the sprint length I want to facilitate teams in identifying what is the root cause of their difficulties. Many times I have found that the problems are either technical or external difficulties. Technical difficulties such as:

• executing manual testing takes too long
• not enough support from QA department for testing each sprint
• build takes too long to validate and deploy
• too much technical debt

are something that the team can start to work on. A team must work with their Product Owner to understand the technical issues and what they will get in return for fixing the most important ones. External difficulties may come in the form of:

• sign off takes too long from external person in organization
• cannot deploy into external environments easily
• not able to get key people with special skill sets on team

and can cause the team problems in getting to potentially shippable code each sprint. It is my opinion that a team should weaken their Definition of Done and identify impediments to getting as close to potentially shippable code as they had hoped. If it is technical then they must get items in the Product Backlog. If it is external then the ScrumMaster must shepherd the impediments to resolution or make step-wise progress on addressing them. Take care of the impediments and the sprint length will become less of a problem.

Team Makeup

If the team makeup is changed then the velocity will change. There are many factors that cause this to happen:

• skill set differences
• bringing new person up to speed
• reduction in team size
• personality problems

The most effective Scrum teams that I have witnessed have worked together, at least a core group, for some time. If your organization is having difficulty keeping teams together then there is an organizational impediment that must be addressed. What about the way work flows to the teams causes them to continually get broken up and reconfigured? Organizations that can give work to teams rather than reconfiguring teams to match the work will have more success with Scrum.

Sizing Nomenclature

Although this is part of the function of team velocity, in my experience it is rare that teams modify their sizing nomenclature. Usually this happens when they first start Scrum where they change from duration-based estimation to estimating size and then deriving duration after executing a number of sprints. If the sizing nomenclature is changed from 2n to Fibonacci sequence there could be a significant change in velocity numbers. Fibonacci sequence produces a curve that rises at a much shorter slope than 2n. 2n is used by teams who have significant risk in technology knowledge on the team, such as in using new platform or R&D. The technical knowledge may lessen over time and they might decide to change their sizing nomenclature to Fibonacci instead. This will have an effect but, again, this has been rare in my experience.

Product

It can’t be said enough but:

Team velocity cannot be compared across teams! – Take NOTE managers!

If teams are working on different products, and therefore different Product Backlogs, then they will have to consider different contextual issues when deriving their velocity for planning efforts. Velocity is most useful when all parts of the team velocity function above is staying consistent. Teams should understand this and if they start working on a different product such as:

• another project
• new initiative
• or an actual different product

then they should understand that their team velocity will be affected.

Conclusion

Consider the items described in this article that can affect team velocity usefulness in your own projects. Team velocity is a:

function of (sprint length, team makeup, sizing nomenclature, product)

If any part of this function is modified then it will affect your team velocity. Bring this up amongst the team and management so that it can be discussed honestly and dealt with in a reasonable way.

“Agile Challenges Clinic/Swap Meet”
Thursday, 26 March 2009
6:30 to 8:30 p.m.
Locations on the Eastside and Seattle!
Read on for agenda and location information, or visit our Google Group at
http://groups.google.com/group/beyondagile

The Blurb
At the first event, everyone (over forty people) created a backlog of ideas, suggestions, and work items. Among them were two suggestions that gave rise to this event’s focus: “a bring-a-problem” session where everyone helps everyone with their challenges. We’ve extended the idea of a clinic, where you bring a problem to an expert and get help, to a swap meet (or potluck), were everyone brings something and gets something. So come if you think you’re brimming over with answers and expertise, and come if you’re wanting other perspectives or advice on how to tangle with the problems that bedevil your days.

We’ll also form a program team, a group that’ll work proactively to plan interesting and exciting events in sufficient time for the blurb-writer–that’s me–to write and distribute the blurb a few weeks before the event. If you’re wondering who’d be good at doing that, go look in a mirror—it’s you we need!

Second Event Agenda

• Welcome and Announcements (10 min.)
• Formation of Program Team (10 min.)
• “Agile Clinic/Swap Meet (85 min.)
• Giveaway Drawing (5 min.)
• Meeting Retrospective (10 min.)
• Socializing and Breakout/Breakup/Beer

Event Locations

Eastside: SolutionsIQ
First Floor Training Center
10785 Willows Road NE, Suite 250
Redmond, WA
NOTE: directions and picture of building at http://www.solutionsiq.com/about-us/contact-us.php?Look for the tent signs and the blue BeyondAgile logo

Seattle: Amdocs Digital Commerce Division (formerly QPass)
Greece Room
2211 Elliott Ave Suite 400
Seattle, WA

Questions?
Contact us at beyondagile@taoproductions.com, or visit our Google Group, or contribute to the nascent Wiki at beyondagile.org.

Why come?
Here’s your chance to be in on the beginning of an exciting new collaboration of the Puget-Sound area (and beyond!) agile-interested. And if that’s not enough, we’ll hold a drawing to win exciting and valuable prizes!

What’s BeyondAgile?
It’s the combination and follow-on to a number of the agile-oriented user and interest groups that have operated in the Puget Sound area. Representatives of the Seattle XP User Group and Seattle Scrum came together in December to try and combine the efforts of all of us who care about and use agile methods.

Why does BeyondAgile exist?
o Find best practices among all agile processes
o Build a bigger agile community
o Take advantage of overlaps between existing groups
o Expand beyond meetings and provide a place to collaborate
o Align software development and business
o Explore cutting-edge ideas and techniques

What is BeyondAgile like?
That, in large part, is up to you. A primary reason for consolidating our efforts is to broaden our base of support, capability, and leadership. We envision a more active, multi-faceted organization that does more than just host talking heads. We’ll gather at least once a month on the 4th Thursday of the month, and probably more often, once you figure out what other events you’d like.

Where do BeyondAgile events happen?
Our goal is to have many answers to this. As a result, we’ve worked to remove the impediment offered by bridges and commuting: for our monthly meetings, we hold our events in both Eastside and Seattle locations, through the semi-magic of videocasting. We’re experimenting: we’ve thought of trying to alternate the “real” physical meeting between sides of the lake. At this point, we’re only at the stage of using a semi-okayish video link between the two locations, and try *very* hard to make the meeting balanced between locations. That’s harder than it seems; come and help us work it out! We’re still dreaming of enabling people anywhere to attend through streaming video, even after the meeting’s already happened, but we need more knowledge, resources, and volunteers before that’s going to happen.

I have question for you.
Great! Visit the Google Group (BeyondAgile) or send a message to beyondagile@taoproductions.com

• I work on features that cut across all or most of the teams, how can I possibly work with all of them?
• I am the only person or part of a small group that supports all of the teams, how will they work with me?
• Our department handles all of these aspects of software delivery, how will we assure quality won’t go down?

As has been said many times by many individuals, Scrum is NOT a silver bullet and it will NOT solve your problems. Scrum will make your problems visible and then it is up to the people within your organization to fix the problems. This is why I believe that the greater your organization can exhibit the five value of Scrum the greater success they will achieve with Scrum. Here are the five values:

• Courage
• Commitment
• Openness
• Respect
• Focus

I want to point out that all of these are needed, in double order, when we find out that people within an organization are “shared”. These people are usually called “shared resources” and anytime that I hear the word “resources” used to identify people it causes me to flinch. “Resources” can be moved around wherever they are needed with specific objectives and not a worry about how they will interact with people around them. At least this is my experience in discussions about moving “resources” around the organization. I like to call human beings “people” and even call them out by name because this causes people who are discussing their movement to address their skill sets and interactions more explicitly. OK, enough of my rant on “resources” versus “people”.

Courage is needed for management to acknowledge that sharing people across Scrum teams is going to cause a bottleneck and to take action. I have found that this phenomenon of going through a single source for that person’s function was already causing a bottleneck but the “hand off” culture allows it to hide from daily view. It takes commitment of either funds for more people or a program to distribute knowledge through mentoring for parts of this person’s functional role. It takes openness on the part of a person who is being “shared” too thin to point it out and make sure that something is done about it. Respect is necessary for all involved to assess the situation and ask for help in resolving the issue. Finally, focus is the value that guides us towards working with one team or at least one Product Backlog at a time.

Depending upon the granularity at which a person functions well, you may find working with a Scrum team or on the Product Backlog a better choice. If your functional role supports the delivery of technical functionality in terms of software development artifacts that are actually used by your end users then being on a Scrum team is better. If your functional role influences the product strategically but does not directly generate software development artifacts that end users use then working with a Product Owner ahead of the Scrum team may be more appropriate. Here are some symptoms of sharing people too thin:

• People mentioning that there are too many meetings
• Scrum teams waiting on dependent artifacts to be delivered
• People working overtime continually to keep up with demand
• Mentioning vacation time causes multiple organizational groups to think about how they will get along while a person is gone

Sharing people is always a potential bottleneck within an organization. Your organization may be able to function for a while with shared people but at some point, if you are lucky and your company grows, they will become spread too thin. Scrum can help you identify this problem and make it visible but it takes people in your organization with courage, commitment, openness, respect, and an eye on focus to fix the sharing of people too thin. Look for ways to find the granularity at which that person in their functional role works within the software delivery process and figure out how they can interact at that level for more appropriate focus and results.