Four Factors that Define a “Healthy” Product Backlog

I’ve been creating a product backlog for a new initiative recently and the exercise got me thinking about how you assess how good it is. After all, a product backlog isn’t a static set of requirements in the traditional sense. No, a product backlog is more of a dynamic “stream” of requirements originating from business needs and flowing through the Product Owner to the Developers who ultimately deliver completed work.

Since the product backlog is a key component of making the switch to Scrum successful, we ought to be able to assess what exactly constitutes a healthy product backlog. This article identifies four factors for consideration:

Factor 1: Are there enough backlog items to support the next sprint planning meeting?

This is easily determined by taking the velocity, which is the average number of story points completed in previous sprints, and comparing it against the points of Sprint Ready items. It will be quite apparent if there’s enough work or not ready for the next Sprint Planning meeting. Consider this example:

If the Developers’ velocity is less than 30, then the Product Owner needn’t worry because enough backlog items are Sprint Ready and available for selection during the next Sprint Planning meeting. If the velocity is 35, the team will need to select backlog items that haven’t yet been reviewed and could spend much more time in the Sprint Planning meeting working through the details. This isn’t a terrible situation but it may require the Product Owner to scramble and answer questions before the sprint work actually starts.

Ideally there should be two sprints worth of backlog items in the Sprint Ready stage. Assuming a velocity of 25, then having 50 points worth of items would create a nice buffer in the event the Developers want to select additional work for the sprint.

Factor 2: Are the individual backlog items actively maintained?

The product backlog is a repository for all sorts of product ideas. Some ideas will represent small enhancements and others will describe large scale efforts. The Product Owner must continually maintain, or “groom”, backlog items with the goal of making them as refined as possible so they can be selected into a sprint.

When a product backlog is first created, the ratio of general to refined backlog items will be high:

The Product Owner will need to spend significant time decomposing those general ideas into properly formatted backlog items. As items are previewed by the Developers during Story Time meetings and feedback is given, the items will be refined further still and become Sprint Ready. At this stage the Developers can select them into a sprint and be confident they know enough about the requirements to complete the work.

Factor 3: Are the individual backlog items ordered according to business priority?

When adding items into the product backlog, it’s good practice to place any new backlog item in the approximate position that represents their business priority. This is true even if the newest entry is only a placeholder.

Once backlog items are refined enough, their placement in the order needs to be more certain. Now, the good news is that the entire product backlog doesn’t have to be perfectly ordered but as the items get closer to the top, they should be so they are ready for the next Sprint Planning meeting. In this example the green backlog items are considered Sprint Ready and have been purposely ordered by the Product Owner.

You may have noticed there are two items with a “3” label. That’s because sometimes there’s just no easy way to decide which one is more important than the other but as long as they’re together and placed relative to all the other items that works just fine. At the next Sprint Planning meeting it may become obvious which is the best for third place but before then there’s little point in solving this puzzle.

The orange colored items aren’t in the final order but are close enough while the Product Owner continues to work on refining them and making them ready for the Developers to review.

Factor 4: Is the minimum marketable feature set clearly defined?

A product backlog will grow over time with the addition of new backlog items but not all are necessary for a specific release. Assuming the product backlog is ordered according to business priority, the Product Owner should designate which items are part of the minimum marketable feature set or MMF for short.

The MMF can include any type of backlog item from those that are Sprint Ready to the most vaguely written but what’s important is that the set is clearly defined. While this designation seems arbitrary, it serves to inform others about what will be included in the release and helps keep the Product Owner focused on what the Developers should be working on in order to finish the release. There will be constant temptation to add enhancements to the release but each one can expand the scope and that may push the release date out.

The MMF serves as a test where the Product Owner asks themselves the question: “Is adding this backlog item worth pushing the release date out?” If the answer isn’t yes, the latest item should be left out of the MMF and included in the next release.

Summary of the factors for a healthy product backlog:

  1.  There are enough backlog items to support the next sprint and ideally two sprints.
  2.  The backlog items are actively updated and refined by the Product Owner.
  3.  The product backlog is ordered according to business priority.
  4.  A minimum marketable feature set (MMF) is defined.

© 2012 William Patrick Swisher

Posted in agile, Backlog Items, product backlog, Sprint Planning | Tagged , , , | Leave a comment

5 Signs Scrum is Working in Your Organization

An organization’s switch to Scrum is really a journey, not a destination, so it’s hard to tell when you’ve arrived. In the beginning there will be many dramatic changes and over time the pace of process improvements will slow but because an essential component of Scrum includes continual inspection and adaptation, the journey should continue ad infinitum. There are signs however that than organization is benefiting from the switch to Scrum; here are five of them:

(1) There’s improved visibility into the product development process.

I once heard a senior executive exclaim “We are being held hostage by Engineering!” It seemed an overly dramatic statement at the time but I came to understand her frustration. Software projects were given to Engineering to be estimated for time & cost and once the project was given clearance to start, the whole thing turned into a black box. The Developers were designing, then coding, then re-designing, then coding, then some testing, then re-coding and testing because requirements changed and so on with little to show for all the work and hours racked up.

The frustration of that senior executive came down to this, she simply couldn’t figure out how to provide clients with delivery dates and feature sets because estimates from Engineering couldn’t be pinned with any certainty. After that organization switched to Scrum the regular delivery of completed work provided the visibility into progress and enabled prediction of when clients could see the finished product. Now with satisfying clarity, it was known what features were just finished, what was coming up in the next sprint, along with reasonably accurate completion dates calculated using measured team velocity.

(2) There’s less ‘Product vs Engineering’ mentality.

I’ve worked in several software development organization and it has always amazed me how the “us vs them” attitude exists between Engineering and Product Management. Just to be clear, both parties can exhibit this attitude. One of the best parts of Scrum is that Product Management, in the role of Product Owner, is closely tied to the Engineering team. No longer are they “tossing requirements over the wall” and coming back after the estimated project duration to see the final product. Every day, they are in the trenches with the Developers hearing about the progress and problems and being immediately available to clarify requirements or make decisions that keep the team moving forward. This close relationship, where they are interdependent, is what erases the “us vs them” mentality as they all succeed or fail together.

(3) The business responds quicker to market needs.

Not much is faster than the “speed of business” where an organization has to frequently change course to address market needs, client demands or discovered defects. Before Scrum, Engineering resources would be tied up in projects for unknown durations and there would be a great deal of negotiation for the reallocation of resources to address emergent business needs. With the short sprint cycles under Scrum, the latest needs (enhancements or issues) wait only a short time in the queue versus having the team finish projects before becoming available. Yes, there can be immediate needs that disrupt a sprint but that is a rare occurrence with most business needs simply waiting for the next sprint.

(4) Product development throughput is higher, much higher.

Before the switch to Scrum, the individual Developers were pulled in multiple directions for various projects, research efforts and called upon to provide technical consultation. This meant that whatever progress was made was inhibited by having to share their time with all the additional work they were tasked with. After switching to Scrum, they are part of a team effort that works on what the business has determined is the most valuable at that point in time and ideally, nothing else. This singular focus enables the team to complete more work and at the end of the sprint be ready for the next set.

(5) Project risks are known earlier.

In the classic Waterfall model, projects go through standard stages of Design, Coding, Testing and Deployment. There can be more stages based on the organization but in general these four represent the essential parts. Risks associated with integration, compatibility, support, workflow or basically how the product will work cannot be known until later in the development process because there’s little to see early on. Under Scrum, because small parts of the final product are completed and delivered each sprint, issues that would otherwise be hidden until later will be exposed. Knowing about such issues or risks early on allows the organization more time to find better solutions. This foresight and ability to maneuver around obstacles sooner just wasn’t possible before using Scrum.

For any given organization there will be various signs the switch to Scrum is being successful but my personal favorite was when a senior executive was heard to say:

“We’re not going back [to Waterfall].”

Now that’s success you can measure.

© 2012 William Patrick Swisher

Posted in agile, Success Factors, Uncategorized | Tagged , , , | Leave a comment

Managing Defects Found During a Sprint

Under the Waterfall software development methodology the typical lifecycle includes Design, Coding, Testing, and Deployment where the separate stages occur in sequence with some parallelization of work depending on the project and organization.

As the name implies and process diagram illustrates, the majority of defects are found later in the process after coding has finished. Then the cycle of testing, fixing defects and retesting continues until a sufficient level of quality has been achieved so the project can be deployed.

However, under the Scrum methodology, coding and testing are closely integrated such that defects are found much sooner and there’s an opportunity to address them quickly.

When a defect (D1) is found for new code introduced in the current sprint, the general rule is “no defect escapes the sprint”. This means that it should be fixed before presenting the backlog item to the Product Owner for Acceptance during the Sprint Review meeting. If the Developers feel the defect is trivial in terms of severity or impact, they can share their viewpoint with the Product Owner who may agree to defer it to the Product Backlog.

When a defect (D3) is not associated with the code being touched in current sprint, the
Developers should bring it to the attention of the Product Owner and allow him to prioritize when it should be addressed. If it is important enough to fix within the current sprint, the whole team (Developers and Product Owner) can negotiate how to get it done. This negotiation may require changing current sprint scope to accommodate it but if the disruption is too great, the Product Owner may decide to wait and add it to the Product Backlog for a future sprint.

Often such decisions aren’t so black & white and a defect (D2) may be related to current sprint work but require more time than is available to fix it even with negotiated changes to sprint scope. In this case, the team will defer it and the Product Owner will add it to the top of the Product Backlog to ensure it gets picked up in the very next sprint. This action allows the team to finish the already planned sprint scope and start afresh in the next sprint.

Whatever decision is made, it is important that the circumstances and decision regarding a postponed defect are documented along with the defect details so future reviewers of the team’s activities and Product Backlog can understand the decisions made at the time.

© 2012 William Patrick Swisher

Posted in agile, Backlog Items, defects, Flexibility, product backlog | Tagged , , | 3 Comments

When are Backlog Items “Sprint Ready”?

In Scrum, the Product Owner creates and maintains the Product Backlog which represents business needs in the form of backlog items. These items can be at various stages of refinement, generally with the vaguest ideas at the bottom and the most complete ones near the top. It’s in the best interest of the Product Owner to ensure that the top backlog items are complete enough for Developers to select during Sprint Planning. So the important question is: When is a backlog item “Sprint Ready”?

Let’s answer that question by identifying the classic parts of a properly constructed backlog item. First, there’s the User Story, a brief narrative that describes (a) who will benefit from the backlog item, (b) what business value is desired, and (c) why it is wanted. Here’s an example based on a website project:

As a member of the service,

I want the website to remember my username & password

so I can get to my account page quickly.

For some Product Owners, writing in this format is challenging or even silly so if providing the narrative isn’t possible, they can at least include answers to the three parts:

(a) Who: paying members of the service

(b) What: a feature that will allow the member to enter the website without logging in each time

(c) Why: so they can get to their account page quickly

The User Story is incredibly valuable because it provides the Developers with the context of the request and makes them partners in the delivery of business value, not just robots obediently processing requirements.

The second part of a backlog item are the Acceptance Criteria which define the conditions the Product Owner requires to consider the work complete and Acceptable at the end of the sprint. These are generally written at the business level, that is, in terms that convey the value for the “who” part of the User Story. They may also include more technical details where the Product Owner wants to be specific about what they want. Continuing with the example about usernames & passwords above:

  • The member must have the option of having the service remember or not.
  • The maximum time to remember a username or password is 30 days.
  • The ‘remember me’ service must be disabled when the browser is from outside the USA.

With an understandable User Story and clear Acceptance Criteria, most people would assume this is enough. But like the two-legged stool illustration, it won’t carry the weight of implementation efforts.

The missing third leg is represented by the Questions the Developers will ask and the final, definitive Answers provided by the Product Owner that clarify the backlog item. For example, after reading the second Acceptance Criteria above, a Developer might ask:

  • Did you want 30 calendar days or just increment the month? => 30 calendar days.

When documented as part of the backlog item, the Product Owner’s answer should immediately follow so any future reader gains the benefit of the new information.

Sometimes a backlog items seems perfectly clear until the Developers start coding, then questions related to implementation come up. Another Developer question might be:

  • What should happen if the browser blocks the storage of cookies? => Remove the option to remember the username & password.

As questions are answered, it may make sense to incorporate them into the Acceptance Criteria versus having a long list of Q&A. The first question regarding 30 days is a good example where the Acceptance Criteria could have been clarified:

  • The maximum time to remember a username or password is 30 calendar days.

Developer questions are inevitable, even the most experienced Product Owner may not think of all the details which is why it is important that the Developers have an opportunity to review upcoming backlog items and ask those questions. Ideally this is done during a Story Time Meeting that occurs prior to when the backlog items are likely to be selected during Sprint Planning but with with enough time for the Product Owner to update the Product Backlog. At this meeting, the Product Owner “tells a story” about upcoming backlog items and the Developers ask questions or provide feedback on how to make more clear.

In summary, the question of “When is a backlog item ‘Sprint Ready?’”, the answer is:

  1. When there’s a complete and understandable User Story and;
  2. there are clear Acceptance Criteria describing specific conditions with no ambiguity and;
  3. the Developers have had an opportunity to review the backlog item, provide feedback, and have enough of their questions answered to begin implementation.

That’s when the backlog item is truly “Sprint Ready”!

© 2012 William Patrick Swisher

Posted in Acceptance Criteria, agile, Backlog Items, Sprint Planning, Uncategorized, User Story | Tagged , , , , | 2 Comments

Lessons Learned Managing Outsourced Scrum Teams

After an organization has successfully switched to Scrum and it needs to engage an outsourced Vendor for technical work, the Client will generally prefer that the Vendor also use Scrum. Scrum’s main benefits of transparency and repeated incremental delivery of finished work will be doubly valuable when working with an outside organization.

The following are a collection of lessons learned from managing outsourced Scrum Teams. The techniques suggested will enhance the relationship and productivity of the outsourced teams and boost the return on investment for the Client organization.

Creating a Partnership, not just a Relationship

When a Client contracts with a Vendor to provide some service there’s an inherent understanding about the relationship between the two parties. Basically, the Client is in the position of power and the Vendor is supposed to do what they are told. This may be the norm but it’s not the best model for when the Client is the Product Owner and the Vendor is supplying the Developers of a Scrum Team.

In this case, both the Client and Vendor should strive to create a partnership and an atmosphere of collaboration. This will be the best for operating under the Scrum methodology, and result in greater productivity and quicker delivery.

Building a partnership starts with how the Client communicates with the Vendor. It is important that  respectful language and terminology to be used, essentially treating them as if they were new employees of the same company working down the hall. This alone will go a long way towards creating a collaborative atmosphere.

Also important is for the Client to set the Vendor up with the means for success. Providing project overviews, instructions, tools, training, and being available for questions, especially in the early stages, is absolutely vital. As the Client, it may be tempting to just “let them figure it out”, after all, the Client is paying for the service. However, investing time and effort in the beginning will result in a Vendor team that understands and produces quicker.

Building a positive working relationship takes time and both parties should do their best to cooperate and explain their positions clearly until the team members get to know each other’s styles better. If a relationship ever becomes antagonistic, it’s very hard to recover from this.

Setting up Conference Calls, Hardware, and Locations

Unless the Client’s team is planning on making numerous trips to the Vendor’s location, most meetings will occur over the telephone. Under the Scrum methodology, there’s a standard set of rituals (Sprint Planning, Daily Stand-ups, Sprint Reviews & Retrospectives) and each of these should be set up as reoccurring meetings at a time that’s convenient for both parties. When the Client and Vendor are in different timezones, be careful to pick times that won’t cause undue strain on either party because while they’ll be willing at first, they’ll become resistant later. All meeting invitations should include clear instruction on how to connect to the conference line and what to do when it doesn’t work. Setting a maximum time limit to wait and a backup number are a good way to ensure someone can get through and deal with the broken connectivity when it occurs.

Once conference call meetings are established with all the necessary information, attention must be given to the equipment and room to be used. Desktop phones often have a speakerphone function but they’re not ideal because the speaker serves double-duty as the microphone. With one of these phones the sound can be choppy because as sounds are picked up on one side, it can cut the other side off. Investing in a conferencing system is worthwhile because they are designed for synchronous conversations and often have satellite microphones for placement around a larger room.

The room design, furniture and adornments can impact the sound quality of a conference call. When we’re physically in a room we don’t notice all the noise that a hard floor, rocky table, squeaky chair, or loose whiteboard can make. We are vaguely aware of these sounds but because we’re in the room and there’s a correlation with someone or something causing it, we automatically filter it out. From the other side of a conference call however, these snaps, crackles, and pops occur randomly and may be as loud as the voices in the room. Closing your eyes and focusing on all the sounds in a room will give an indication of what might be causing disruptive noises.

Whenever possible, participants should sit equidistant from the conference system’s microphones and adjust their position depending on the power of their voice. Whatever equipment or facilities are to be used, it’s a good idea for the leaders of the team to test the experience and made any adjustments before serious meetings get started. Small distractions build into frustration and that will impact the working relationship and productivity of the teams.

Using Remote Viewing Software

Meetings regarding software development will benefit greatly from being able to share a screen, either to demonstrate work or for a quick review of code or troubleshooting issues. There are many services available and generally work across platforms so both parties don’t have to be on the same type of computer or operating system. When sharing screens, it’s important to be aware of mouse movements and screen scrolling. Most people move their mouse cursor in quick erratic movements when pointing to something on a screen and scroll very quickly. Remote viewing software doesn’t always keep up with these quick movements and the viewers on the other side will be lost or at least distracted by all the unnecessary movement. Be courteous, slow down, and provide some narrative regarding what is being shown or when a screen is about to be changed.

Trying Video Conferencing

Video conferencing has improved greatly in recent years but may still suffer from pixellation or lag when bandwidth drops. Once the sound and picture of someone talking becomes unsynchronized, it will be a distraction and confuse speakers because they’re getting mixed signals showing when someone has stopped talking and another person can start. Since people like to see who they’re dealing with, an alternative to a video conference is for both the Client and Vendor to exchange a group picture with the other so everyone can see who they’re dealing with. Great fun can be had by asking each team to guess who’s who offline and then view the answers together on another call.

Setting up and All-Inclusive Email Group

Assuming most communication will occur over email, it is useful to create an email group with all participants’ addresses included from the Client and Vendor. This way, as information or issues are discussed, everyone can be aware of what’s going on. Some of the discussion topics may not pertain to everyone and those people can selectively ignore the thread. This technique is very effective when the Client team members have other responsibilities besides working with the Vendor and everyone on the team can help pitch in where needed.

There will be times when it’s more appropriate for a conversation just between two people and in those cases writing directly to them makes sense. If information or a decision comes out of these side-discussions, it’s best to bring that back to the group in summary form versus forwarding the entire conversation which until that point, everyone else wasn’t even aware of.

Creating a Project Contact Information Document

To ensure everyone has a complete listing of all team members, it’s advisable to create a Project Contact Information document and have it shared with all parties. At a minimum it should contain a list of personnel, their contact information (email, phone) and role on the project, grouped by Client/Vendor:

If the Client and Vendor are separated geographically and by timezone, including a list of expected working hours and response times is also useful along with an escalation protocol for unanswered needs:

Periodically updating it and re-sharing through the project email address is important to make sure everyone has the latest copy.

Defining a File Exchange Protocol

Even the most trusted Vendors may not be allowed to connect directly to a Client’s network so sharing files can be challenging. Before a project starts, determine the types of files will need to be exchanged and the best way to accomplish this. Document the file exchange protocol and make sure all parties understand what it defines. This can include instructions on how to package up files, where to deposit them, and who to contact to handle the transfer.

When various file types will be exchanged and not all have the same level of security concern, create a matrix of file types and appropriate delivery channel. For example, project training materials could be sent via email where binaries or source code deliverables should be encrypted and sent more securely. The following table shows how such a matrix could be constructed:

Whatever protocol is established, it should be re-evaluated periodically to ensure it’s still a valid process and adjusted if needed.

Educating the Vendor on Client Methods

The Scrum methodology, with its focus on transparency and incremental delivery of work, is ideal for working with Vendors. However, every Vendor’s understanding of Scrum may not match the Client so it’s advisable to provide some training on the key processes the Client expects the Vendor to adhere to. This shouldn’t be a training session on the basics of Scrum but rather an orientation on how the Client expects the rituals to be performed and what artifacts (Product Backlog, Sprint Backlog) will be used.

Start with Short Sprint Cycles

Most Vendors will be keen to adapt to the Client’s ways but just to make sure the relationship starts off right and the kinks are worked out of the process, the first sprint or two could be shortened to half as long (one week vs two). These short cycles will establish how rituals are supposed to work and get all parties used to working with each other. This will incur some overhead as the time between Sprint Planning and Review are very short but will help establish a solid foundation for the subsequent sprints.

Building Trust

In the beginning of a Client / Vendor relationship, the Vendor will maintain tight control on their internal issues and processes and expose little of how the work actually gets done. Keeping a positive appearance is not unlike what the Client does for its customers where the best image is projected and any chaotic background activity is kept strictly hidden. Unfortunately, the tendency to gloss over issues and impediments is contrary to Scrum where even the smallest hinderance should be exposed and resolved to maintain the productivity of the team. There will always be something the Vendor would rather not talk about but an atmosphere of trust and collaboration should be encouraged by the Client. This can be done in two ways, (1) to always ask directly if there are any unanswered questions or needs and address them immediately and (2) never react in a strong, negative way to bad news for it will teach the Vendor to avoid bringing such things up. Over time, the two parties will be more comfortable exposing issues and working to resolve them. This is the essence of building a partnership and not just a Client / Vendor relationship.

Managing Questions & Answers

During execution of the project the Vendor will have questions about requirements, Client preferences, et cetera. In the beginning these questions are likely to be simple and relatively few but as the Vendor picks up speed the frequency and difficulty will increase. Some questions can be answered right away and others will take days of research.

The natural inclination of the modern office worker is to use email for tracking open questions but this quickly becomes overwhelming because of all the back-and-forth on a given topic and more importantly, the Inbox is the hub of our working lives and Vendor questions could be buried in all the traffic. Email can certainly be used to have a conversation about questions, but it is best to record and track questions in a single repository so there’s one source of information everyone shares.

Creating a repository is easily done with a spreadsheet program and a successful design depends not on including everything about the issues but just the essential set needed for sharing and tracking. The following example illustrates this point:

Each of the columns serves a specific purpose:

  • ID# – Each row should have a unique identifier for referencing during conference calls and emails.
  • Topic – This column is primarily to help the viewer get a sense of what the issue is about. It can be freeform text or a standard set of choices, whatever the teams prefer.
  • Question – Since these questions will be reviewed and worked on outside of meetings, it is important that context be provided along with a clear request. Ideally there should only be one question per row otherwise answers could be confused and progress will seem limited as list of unanswered questions builds up.
  • Answer – Answers should be concise and to the point. Any ambiguity will only prolong reaching resolution. Additionally, these question/answer pairs serve as a record of project requirements.
  • Status – New questions have a status of ‘Open’ and when they are answered, ‘Closed’. This serves to identify which issue still require attention.

A Priority column can be added when there tends to be more open questions than a team can keep up with and it will be necessary to sort them according to which are the most important to address first.

The file should be shared via central location so both the Client and Vendor can view and update it but if that’s not possible, it can be passed back and forth via email but with one party responsible for its upkeep.

Conversation Tips

Conference calls provide no visual cues to those on the phone and even when a decent video conference system is in place it doesn’t provide the same experience as when everyone is in the room. The following tips will improve communication between all parties.

  1. When asking questions, provide context and then state the question directly, making sure it has a clear endpoint. E.g. “In the user interface mockups sent yesterday, the call-to-action buttons aren’t all the same color; which color is the correct one?”
  2. When answering complex questions, summarize the question, ask for validation, then provide a concise answer. E.g. “Let me make sure I understand what you’re asking. You want to know if the database schema is for the testing or development environment.” “Right, ok, it is for the testing environment.”
  3. When directing a question or answer specifically to one individual, address them by name. E.g. “Thomas, the code I updated will affect what you checked in last night.” “Richard, did you receive the file I FTP’d yesterday?”
  4. When you need to discuss something with the local team, let everyone on the conference call know you you need to have a side conversation so they’re not wondering if they should be engaged in the discussion. E.g. “Hey guys, hold on a minute, I need to clarify something with Harriet here.”
  5. When you need a moment to think about an answer or topic, inform the call participants that you need a moment to gather your thoughts. E.g. “Hold on a moment everyone while I think this through.” “Ok, here’s what we’ll do…”

These suggestion will add overhead to the conversation but will give both parties the necessary signals for smoother collaboration and will pay off as the project executes.

Project Manager Coordination

Getting two groups of people to work together isn’t trivial and especially so when they are separated by distance, timezone, or culture. Some form of friction should be expected with communication and established procedures. These issues will generally work themselves out in time but to quicken a positive outcome the two Project Managers, or equivalent roles, should meet periodically and have an open and honest conversation about how they feel the relationship is going and how the teams are interacting.

These conversations should be constructive with clear goals defined for addressing perceived issues and then evaluated during subsequent meetings in order to monitor progress. The two people should not think of themselves as being on either the Client or Vendor team but on a third team interested only in the success that a productive relationship can bring.

Not every issue can be solved quickly but if both parties make the necessary adjustments for each team everyone benefits.

© 2012 William Patrick Swisher

Posted in Offshoring, Outsourcing, Partnership, Uncategorized, Vendor Management | Tagged , , , | 4 Comments

Book: “Switching to Scrum” is now available!

I’m very pleased to announce that my latest book:

Switching to Scrum

How to Implement Scrum in your Software Development Organization

is finally available for purchase at!

Topics in this book include:

    • Making key decisions and organizational messaging
    • Utilizing existing business requirements for Scrum development
    • Creating a Product Backlog, writing backlog items and managing defects
    • Preparing for the first Scrum Team and project
    • Initiating software development with Scrum
    • Monitoring the transformation process and making adjustments
    • Expanding the number of Scrum Teams
    • Measuring transformation success
    • Includes many templates and sample artifacts to kickstart the transformation

A Kindle edition will be coming soon.

Posted in agile, book, Uncategorized | Tagged , , , | Leave a comment

What is a Burndown Chart and What Does it Tell Me?

© 2012 William Patrick Swisher

Burndown charts are a highly effective tool for monitoring progress during a sprint. There are a variety of ways to create this chart including:

  • Tracking the remaining hours for unfinished tasks.
  • Tracking the number of unfinished tasks.
  • Tracking the number of completed backlog items within a sprint.
  • Tracking the sum of story points earned within a sprint.

Assuming a Scrum Team breaks down backlog items into tasks and each day reports on remaining hours for those tasks, the resulting burndown chart can provide a nice visual of the team’s trajectory towards being finished with all sprint work. Here’s what a typical burndown chart would look like:

You’ll notice the red dotted line starting at the top left and traversing to the bottom right of the chart. That’s the “ideal burndown line” or “guideline” that provides a simple guide to how much work ought to be completed each day in order to finish everything at the end of the sprint.

The team’s progress, as measured by remaining hours, tends to decrease over the course of the sprint. There can be interesting patterns, some of which are cause for concern whereas others are not. In the following example the burndown line starts to turn upwards mid-sprint. The Scrum Team should identify what’s causing the uptick and how they might address it so that they can complete all sprint work in the remaining days.

However, if the upward trend was very early in the sprint, this may simply be a result of the team discovering more tasks or an increase in hours for existing tasks. The Scrum Master should watch the trend and if it continues to climb, the team can have a conversation about how to address it.

On the other hand, if the burndown line is headed to zero much quicker than the guideline, the Product Owner should make sure the Product Backlog’s top items are ready for possible selection into the sprint as the team will be looking for work soon.

In general the burndown chart is a basic gauge used for measuring progress and should spark conversations when problem patterns appear.

Posted in Burndown Charts | Tagged , , , | Leave a comment