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.

What should the software do next for the user?

The following coding session will provide an example of applying this question. The fictitious application is a micro-blogging tool named “Jitter”. This is a Seattle-based fictitious company that focuses on enabling coffee injected folks write short messages and have common online messaging shorthand to be expanded for easy reading. The user story we are working on is:

So that it is easier to keep up with my kid’s messages, Mothers want to automatically expand their kid’s shorthand

The acceptance criteria for this user story are:

• LOL, AFAIK, and TTYL are expandable
• Able to expand lower and upper case versions of shorthand

The existing code already includes a JitterSession class that users obtain when they authenticate into Jitter to see messages from other people they are following. Mothers can follow their children in this application and so will see their messages in the list of new messages. The client application will automatically expand all of the messages written in shorthand.

The following programmer test expects to expand LOL to “laughing out loud” inside the next message in the JitterSession.

public class WhenUsersWantToExpandMessagesThatContainShorthandTest {

    @Test
    public void shouldExpandLOLToLaughingOutLoud() {
        JitterSession session = mock(JitterSession.class);
        when(session.getNextMessage()).thenReturn("Expand LOL please");
        MessageExpander expander = new MessageExpander(session);
        assertThat(expander.getNextMessage(), equalTo("Expand laughing out loud please"));
    }

}

The MessageExpander class did not exist so along the way I created a skeleton of this class to make the code compile. Once the assertion is failing, I then make the test pass with the following implementation code inside the MessageExpander class:

public String getNextMessage() {
    String msg = session.getNextMessage();
    return msg.replaceAll("LOL", "laughing out loud");
}

This is the most basic message expansion I could do for only one instance of shorthand text. I notice that there are different variations of the message that I want to handle. What if LOL is written in lower case? What if it is written as “Lol”? Should it be expanded? Also, what if some variation of LOL is inside a word? It probably should not expand the shorthand in that case except if the characters surrounding it are symbols, not letters. I write all of this down in the programmer test as comments so I don’t forget about all of these.

// shouldExpandLOLIfLowerCase
// shouldNotExpandLOLIfMixedCase
// shouldNotExpandLOLIfInsideWord
// shouldExpandIfSurroundingCharactersAreNotLetters

I then start working through this list of test cases to enhance the message expansion capabilities in Jitter.

@Test
public void shouldExpandLOLIfLowerCase() {
    when(session.getNextMessage()).thenReturn("Expand lol please");
    MessageExpander expander = new MessageExpander(session);
    assertThat(expander.getNextMessage(), equalTo("Expand laughing out loud please"));
}

This forced me to use the java.util.regex.Pattern class to handle case insensitivity.

public String getNextMessage() {
    String msg = session.getNextMessage();
    return Pattern.compile("LOL", Pattern.CASE_INSENSITIVE).matcher(msg).replaceAll("laughing out loud");
}

Now make it so mixed case versions of LOL are not expanded.

@Test
public void shouldNotExpandLOLIfMixedCase() {
    String msg = "Do not expand Lol please";
    when(session.getNextMessage()).thenReturn(msg);
    MessageExpander expander = new MessageExpander(session);
    assertThat(expander.getNextMessage(), equalTo(msg));
}

This forced me to stop using the Pattern.CASE_INSENSITIVE flag in the pattern compilation. Instead I tell it to match only “LOL” or “lol” for replacement.

public String getNextMessage() {
    String msg = session.getNextMessage();
    return Pattern.compile("LOL|lol").matcher(msg).replaceAll("laughing out loud");
}

Next we’ll make sure that if LOL is inside a word it is not expanded.

@Test
public void shouldNotExpandLOLIfInsideWord() {
    String msg = "Do not expand PLOL or LOLP or PLOLP please";
    when(session.getNextMessage()).thenReturn(msg);
    MessageExpander expander = new MessageExpander(session);
    assertThat(expander.getNextMessage(), equalTo(msg));
}

The pattern matching is now modified to use spaces around each variation of valid LOL shorthand.

return Pattern.compile("\\sLOL\\s|\\slol\\s").matcher(msg).replaceAll("laughing out loud");

Finally, it is important that if the characters around LOL are not letters it still expands.

@Test
public void shouldExpandIfSurroundingCharactersAreNotLetters() {
    when(session.getNextMessage()).thenReturn("Expand .lol! please");
    MessageExpander expander = new MessageExpander(session);
    assertThat(expander.getNextMessage(), equalTo("Expand .laughing out loud! please"));
}

The final implementation of the pattern matching code looks as follows.

return Pattern.compile("\\bLOL\\b|\\blol\\b").matcher(msg).replaceAll("laughing out loud");

I will defer refactoring this implementation until I have to expand additional instances of shorthand text. It just so happens that our acceptance criterion for the user story asks that AFAIK and TTYL are expanded, as well. I won’t show the code for the other shorthand variations in the acceptance criteria. However, I do want to discuss how the focus on “what should the software do next” drove the design of this small component.

Driving the software development using TDD focusing on what the software should do next helps guide us to only implement what is needed and with 100% programmer test coverage for all lines of code. For those who have some experience with object-oriented programming will implement the code with high cohesion, modules focused on specific responsibilities, and low coupling, modules that make few assumptions about other module they interact with will do. This is supported by the disciplined application of TDD. The failing programmer test represents something that the software does not do yet. We focus on modifying the software with the simplest implementation that will make the programmer test pass. Then we focus on enhancing the software’s design with the refactoring step. It has been my experience that refactoring refactoring represents most of the effort expended when doing TDD effectively.

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 9621 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 9621 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 9621, 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.

The first one that I would like to discuss is the:

Keep your Product Backlog between 50 and 100 items total

This is difficult for some Product Owners at first. They may be collecting items from bug databases, issue tracking, stakeholder requests, and customers. A Product Owner may hear that this list must represent the prioritized list of work to be done on the product and then dump any item they can find into the list without making them easily consumable. Find ways to gather items into larger groupings and remove items that are not on your Product Roadmap yet.

The top 20-40 items are small enough to fit into a team’s Sprint

The top of your Product Backlog represents what is in highest priority to be implemented by the team. It is important to work with the team on making these items small enough for those items to fit into a Sprint. Getting estimates of cost from the team can help a Product Owner guage if the item is small enough to fit into a Sprint. If the item is important but sized too large to fit then the team can help the Product Owner break it down into smaller pieces.

Put acceptance criteria on top 20-40 items

Acceptance criteria could be a bulleted list of capabilities the Product Backlog item should put into the product once it has been implemented. These can be thought of as the functional acceptance tests for the Product Backlog item. If your list of acceptance criteria is getting larger than 7 bullet points then…

Break up Product Backlog items into multiple items when acceptance criteria is larger than 7 capabilities

Of course, there are also times where the Product Backlog item is too small and does not do enough on its own to create value for the product. In that case there is the following rule of thumb…

Each Product Backlog item should have at least 3 acceptance criteria about its implemented capabilities

Having too small of Product Backlog items is not always a bad thing but it could be difficult to manage and provide visibility into. I have found it also leads to Product Backlog items that are technical in nature without business benefit. As a Product Owner, it is usually difficult for me to guage the correct priority for something technical so…

Every Product Backlog item should present value that a Product Owner can understand and prioritize effectively

You may use abuse stories to help drive out the value to users for infrastructure or architecture Product Backlog items as written in this blog entry. However, a Product Owner could work closely with the team to delve into the value of their technical items through questions and learning. It is important that a Product Owner does not take the team’s technical items too lightly since those could be capabilities that allow your release to be successful. Such as scaling to meet your 100,000 users on the site at once.

The entire Product Backlog should be prioritized in stack rank order and…

The entire Product Backlog should be estimated by the team who is going to work off of it

These are the basics for Product Backlog management but I thought I should reiterate them. I often find that the Product Owner does not take time to prioritize their entire Product Backlog. The Product Backlog provides visibility to stakeholders, management, and the team about how the product is proposed to move forward. It is sometimes difficult to prioritize if the Product Owner does not have a cost to weigh against the benefit for each Product Backlog item. The team who is actually going to implement items off the Product Backlog should be the ones who estimate it as a group. Not any individual outside the group who will tell the team how long they should be taking on each item. From this costing of the Product Backlog it is possible to…

Generate a release burndown to monitor the release plan

Once you know how much the team can take on each Sprint you can do some ad-hoc release planning by going through your estimated Product Backlog and finding out how far they will be after n number of Sprints. Once you put this on a Release Burndown you can monitor that release and see if any changes must be made to the plan based on the reality of implementation or emergent requirements. You may even hold a Release Planning event with your entire team, stakeholders, and other interested parties to create a subset of your Product Backlog that is expected to be in the next release. With all of these parties coming together, a Product Owner may get more items to put into their Product Backlog where gaps were found by the team and stakeholders.

This listing of some Product Backlog rules of thumb is just a start. I have found it helpful to go through this list with new or troubled Product Owners. Please let me know if you have any other items for the list or if you disagree with some. I am always interested in what others have found helpful.

I don’t believe that this entry will solve the question but I hope to at least give some focus for teams who are dealing with the structural integrity of their applications. First off, a definition of “architecture”:

architecture: noun – “the art or practice of designing and constructing…” or “the complex or carefully designed structure of something” or “the conceptual structure and logical organization of a computer or computer-based system”

Each of these definitions interests me but to put them to practice is quite difficult. They are left to interpretation about what is design, construction, structure, conceptual, and logical. Earlier interpretations of this term interpreted these to mean the high-level structure, architectural style, and finally the stuff that is too expensive to get wrong.

It seems to me that my interpretation is a bit different. Working with tools, practices, and processes over the past 15 years has guided me to a different conclusion. I believe that architecture is how it is SAID:

Structure – how the pieces (components) create a solution (application)
Alignment – the degree to which the application or enterprise structures align to current business objectives and strategy
Integrity – the components that provide stability to the structure (application or enterprise) (ie. automated tests and builds, service-level agreements, network infrastructure, etc…)
Design – a way to conceptually communicate the planned or implemented structure of a component, application, or enterprise (ie. system of names, XP practice of Metaphor, information radiators, etc…)

Using these as the basic building blocks for teams to focus their efforts can be helpful.

The structure is the reality of the solution’s construction. If the structure is too brittle or complex to support future needs then the structure is not sound. If you have been in the software development industry for even short period of time you have probably seen applications that are too brittle or complex.

If the application or enterprise structures are not aligned with current business needs then the value of those structures have deteriorated. We sometimes keep a specific architecture and force-fit new business needs into it because it once was the right architecture to have or we paid a bunch of money for it. Continual restructuring of our architecture to meet today’s business needs is important.

Providing supports to our structure allows for it withstand changes in the environment such as new business needs and updates in technology. Automated tests and builds help us keep the structural integrity of our applications intact while these changes are introduced into our applications and enterprise.

Communicating the conceptual structure of a component, application, or enterprise is important because it is common for new people to work on them and for those structures to interact with other components and applications. Getting someone up to speed on a component or application involves verbal, tactile, written, and visual examples. Much of what is needed can be kept in or close to the codebase along with conversations with existing developers. It is important to understand how components and applications are currently structure conceptually so we can discuss their interactions with other components and applications. For instance, should we connect via library, SOAP, RPC, or REST?

When I think of application architecture I want to focus on just a few principles:

• Application architecture is about changeability, not longevity
• Application architecture decisions should be made closest to where they are implemented as possible
• Application architecture design is not only about our ability to design a solution but also knowing what components, applications, and solutions already exist
• The value for change in a component’s, application’s, or enterprise’s architecture is directly proportional to the cost of not addressing

If the structure is not able to change as the needs of our business change then the solution will become a liability. If someone other than those who are constructing components and applications are deciding on architecture decisions then there will be important information lost in translation between the two. If we keep using the same design hammer (ie. always using 3-tier or IoC for everything) then we are not allowing the strongest solutions to emerge. The value of architecture can usually be described by the cost incurred if it is not taken care of.

Well, let the onslaught of comments commence. I have put out my ideas on architecture. There are many more out there to discuss and I am sure I will hear some of them. I will finish this entry with a quote from Martin Fowler’s “Who Needs an Architect?” article:

“I define architecture as a word we use when we want to talk about design but want to puff it up to make it sound important.”

SD West 2009 Conference & Expo
March 9–13
Santa Clara Convention Center, Santa Clara, CA
http://www.SDExpo.com/

I’m pleased to announce that I’ll be teaching the following session at SD West 2009:

“Managing Software Debt: Continuing to Deliver High Value as Systems Age” on Friday, March 13th from 3:30-5:00pm

SD West is where the software development community gathers to learn about the latest business-critical technologies, network with peers, connect with innovative vendors and get inspiration from industry visionaries. The comprehensive conference program covers today’s most important topics including cloud computing, concurrent programming, dynamic languages, agile processes, security, testing and much more.

Super early bird conference discounts of up to $400 expire Friday, January 16.  As a speaker, I can also offer you an additional $100 off the VIP Pass. Simply register at http://www.SDExpo.com with the code 9ESPK to get your discount.

Check out all the excellent educational opportunities SD West 2009 has to offer at http://www.SDExpo.com.

I look forward to seeing you in Santa Clara!

• Maintainability
• User manuals
• Training
• Communication
• etc…

Since the idea of Agile software development is not to remove all documentation from software delivery then what is the right amount of documentation? Of course, the answer is it depends but we won’t leave it at that. This article will focus on one area of documentation and that is specifying what users want.

User stories were popularized by Mike Cohn with his book “User Stories Applied”. Many people do not read and take in all of what is provided in Mike’s book before using user stories to capture user desired functionality. Instead they may be introduced to it on the Internet, through a seminar, or in training. The appeal of user stories is they are short statements that are easy to write and fit on 1 index card. The problem, as Ron Jeffries explains it in his article “Card, Conversation, Confirmation”, is the statement written on an index card is not enough information for the development to implement without providing some clarity through conversation with someone who represents the user’s desires. So the first way that user stories “GO WILD!” is:

Stakeholders expecting that a statement written on an index card is enough for the team to implement what they desired in the software

And this can be more generalized as:

User stories inappropriately used and becoming just bad specifications

Development must have conversations with people knowledgable about the user story domain to clarify the desired functionality. And as Ron rightly describes, conversations may be supplemented with documentation when needed. This could be in the form of an user interface design, usability study, business rules, acceptance tests, and any other format necessary for the development team to implement the user story satisfactorily. During the conversation new understanding and clarity of the user story specifics will be drawn out. The next way user stories “GO WILD!” is:

Acceptance criteria (or “Confirmation” as Ron puts it) for the user story is not captured and many times forgotten during implementation

It is important that the development team and domain experts write down important nuggets of knowledge about the desired functionality. This could be as simple as writing it down as bullet points on the back of the index card or creating skeletons of acceptance test cases.

Sometimes teams come across user stories that seem either too ambiguous or potentially mammoth in size. There are some great indicators in the user story text that I have found over the years while working with them over the years. Here are a few ways that user stories “GO WILD!” along with ways to deal with them when they do:

Using conjunctions within the user story statement

Whenever I see an “and” or “or” or “if” or “until” or… well you get the picture… this is an indicator to me that more than one piece of functionality is being described. This is an opportunity to split the user story into multiple user stories usually right where the conjunction was put in.

Describing too much about “how” to implement the user story

It has been common in my experience to see business analysts or technical writers creating user stories to support a Scrum Product Owner or stakeholder group in defining their desired features. You might see phrases such as “when they click on … button”, “drop down”, and “using Excel” which are specific about the “how”. In the past, these people were asked to describe the functionality so it was clear for programmers to code and testers to verify. Now we are asking them to write user stories that describe “what” the user wants and not “how” to implement it. This is a problem since they have used the “how” to make clear requirements for the development team to implement. Agile teams are expected to take more responsibility in defining “how” the software is implemented. This includes providing their input on specifying and designing the software. Many times I have seen specification of features get simplified or enhanced through the conversation between development team and domain experts. We want this to occur more often since these interactions will increase software features delivered and improve the product for its users.

Can’t describe the value provided to the user for the desired functionality

There has been more than one time that I have asked “why are we implementing this user story” and was not provided a satisfactory answer. I may have gotten an answer like “because it is defined in the requirements document”, “because it was prioritized high”, or “because the CEO wanted it”. All of these may be good enough reasons to implement the functionality but it is less likely that the development or domain experts will implement it masterfully given the lack of understand around what the user wants to do with this functionality. Understanding how a user story fits into the bigger picture is important since it will enhance the conceptual integrity of the software overall. When software is implemented by generating many disconnected components and integrating them together into a cohesive package the software tends to become inconsistent in its usage with lots of hidden but potentially useful functionality. Ask yourself when writing a user story why would the user want this functionality. You can use the user story template:

As a [user role] I want to [do something] so that [I gain some benefit or value]

By address the “so that” clause you will provide more understanding of how the functionality fits into the larger picture. Or you may find out that it is not useful at all. In that case, you can throw it away and work on something of more value to your users.

Writing technical user stories in which the value is not understood by the Product Owner or stakeholders

Technical user stories tend to get deprioritized since they are not easily assessed for value by most non-technical people. I have found that it is essential to describe why we have new technical needs or what the cost of not addressing a system’s quality attribute such as scalability could be. I have written an earlier post on this regarding a term coined by Mike Cohn called “abuse stories”. The idea is to capture the cost of not addressing an architectural or infrastructure need by describing it from an abuser of the software’s point of view. Writing technical needs in a user story format is not necessary but may be helpful while building trust between the development team and stakeholders. Sometimes project stakeholders believe that time and money is getting wasted on technical perfection. By writing the abuse story a development team can show that these technical needs are not just wasted efforts but provide value to the software. It is hoped that over time a team can just let their Product Owner or stakeholder group that there is a technical need that must be prioritized before particular functionality should be implemented and that will be enough.

Now that you know some ways that your user stories can “GO WILD!” it is time to tame those user stories so that your software can be the best it can be. Happy story writing! And, oh yeah, happy new year 2009!

Good day George,

I read your blog all the time and enjoy what you write about. This blog entry caught my attention and I had to respond.

The one problem I have with the judgment of “working hard or hardly working” is that is presumes that working hard is always good. A large issue in our industry is the “busy-ness” factor of all people involved in the organization from executives to managers to developers and operations. We all are too busy and therefore our hard work turns into adding more work than if we were to slow down and make better decisions about how to complete the work best.

So, even if someone could tell if another person is “working hard” or “hardly working” I am not sure this is a good measure of anything. In the end I would rather understand if the organization or product team as a whole is getting faster in their delivery of valuable software. If this is the case then all people involved are improving their capabilities for the good of the whole.

Coincidentally, Tom Perry wrote on “Measuring Productivity = Continuous Improvement?” where he makes many references to “monkeys” but also makes a conclusion that teams can create their own productivity metrics to help improve their own delivery capabilities rather than management defining problematic measurements for the team that create poor responses.

Both blog entries have great information and references in them and I hope that those of you interesting in “measuring productivity” take a look. I am still on the Alistair Cockburn side of the house when it comes to measuring productivity. I believe it cannot be done but that doesn’t mean that the team cannot create metrics that help them improve.

And finally I will just point you towards Ron Jeffries wonderful writing on “Productivity” from “Annals of Kate Oneal”.

INVEST your time in telling stories that give you meaning moving on…

Unique perspective inward and outward focused simply understood

The user wishes to do something on the site they do not know why

Start with a user a new or improved feature gives us the value

As a Scrum novice I want to learn this method so that we can plan

The confirmation makes conversation simple and settles details

Not bad for 5 minutes worth of work. Some of the items that were referenced:

• INVEST model
• User Story template
• 3 C’s of a User Story

I would like to add to this listing with some of the tools I have come to use often:

• Maven 2.x+ (http://maven.apache.org/)
• JBoss (http://www.jboss.org/)
• Rio/Jini/Apache River (http://incubator.apache.org/river/RIVER/index.html)
• Apache Commons (http://commons.apache.org/)
• Subversion (http://subversion.tigris.org/)
• Apache Web Server (http://httpd.apache.org/)
• Bouncy Castle (http://www.bouncycastle.org/)
• Time and Money (http://timeandmoney.sourceforge.net/)
• Spring Framework (http://www.springframework.org/)
• Hadoop (http://hadoop.apache.org/)
• Ruby on Rails (http://www.rubyonrails.org/)

This is some of the open source that I have and still use on my projects. What are your favorites that were not on the list?

From my readings of multiple books, articles, and blog postings along with my own experiences with TDD the content of what I am about to distill is not new. This post is entirely about explaining the technique in a way that garners interest quickly. There are multiple pieces to “Executable Design” beyond the basic process of:

• Red, Green, Refactor or
• Write Test, Write Code, Refactor

These statements and the technique is the basis for practicing Executable Design but are not sufficient for describing the value and nuance of the practice. Not that I will be able to present it sufficiently in a single blog post but I want to present the basic principles.

While in a meeting with a team recently we were presented with a question I have heard often:

“Why should we use TDD?”

There are many reasons but generic reasoning alone is not sufficient. We discussed the safety net that good code coverage creates. We discussed the reason system tests do not take the place of unit tests. Then we started to touch on design and this is where it got interesting (and usually it does about this time for me). Before I can describe the rest of this discussion I want to present what lead up to this meeting.

A coach that I highly respect seemed a bit preoccupied one day when he wandered into my team’s area. I asked him what was going on and he told me that some of his issues with the current team he was coaching. He wondered why they were not consistently using TDD in their day-to-day development. The team had allowed a card saying “We do TDD” onto their Working Agreement and were not adhering to it.

I happened to know a bit about the background of this project that our company has been working on for over 2 1/2 years. There is a significant legacy codebase developed over many more years with poor design, multiple open source libraries included, and heavy logic built into relational database stored procedures. Also, just recently management on the client’s side had changed significantly and caused quite a shake up in terms of their participation and guidance of release deliverables. Yet the team was supposed to deliver on a date with certain features that were not well defined. This lead me to discuss the following situations that a coach can find their way into:

1. You could come into a team that has limited pressure on features and schedule and has considered the impact of learning a new technique such as Executable Design. Also, they have asked for a coach to help them implement Executable Design effectively. This is a highly successful situation for a coach to enter.
2. You could come into a team that has deadline pressures but has some leeway on features or vise versa and has considered the impact of learning a new technique such as Executable Design within their current release. Also, they have asked for a coach to help them implement Executable Design effectively. This is somewhat successful but pressures of the release rise and fall in this situation and may impact the effectiveness of the coaching.
3. You could come into a team that has deadline pressures and has not considered implementing Executable Design seriously as a team. Also, they have NOT asked for a coach and yet they have gotten one. The coach and the techniques they are attempting to help the team implement may seem like a distraction to the team’s real work of delivering a release. This is usually not successful and please let me know if you are a person who is somewhat successful in this situation because we could hire you.

The current team situation seemed to be more like #3 above and therefore the lack of success in helping the team adopt TDD did not surprise me. Also, I started to play devil’s advocate and provide a list of reasons for this team NOT to do TDD:

• At current velocity the team is just barely going to make their release date with the minimum feature set
• Not enough people on the team know how to do TDD well enough to continue it’s use without the coach
• The architecture of the system is poor since most logic is captured in Java Server Pages (JSP) and stored procedures
• The code base is large and contains only about 5-10% test coverage at this time
• It sometimes takes 10 times longer to do TDD than just add functionality desired by customer

This is not the full list but you get the picture. Don’t get me wrong, the list above begs to me the need for Executable Design but if the team does not have significant experience to implement it effectively it could seem overhead with little benefit to show for it.

After discussing this and more stuff that I won’t go into he told me about a couple of things that he can do to help the team. One of them was to work on minimizing the reasons for not doing Executable Design by discussing them with their ScrumMaster and actioning them on the impediments list. Some of those actions would go to upper management who get together each day and resolve impediments at an organizational level. One of the actions was to get our CTO and myself into a room with the team so they can ask the question “why should we do TDD?”.

Now we are in the room and most of the team members had been exposed to TDD through pairing sessions. Some of them had some ideas about where TDD was useful and why they thought it was not on this project. During the discussion one of the team members brought up a great discussion point:

“One of the problems with our use of TDD is that we are not using it for improving the design. If we just create unit tests to test the way the code is structured right now it will not do any good. In fact, it seems like we are wasting time putting in unit tests and system tests since they are not helping us implement new functionality faster.”

This team member had just said in the first sentence what I instinctually think when approaching a code base. The reason to do TDD is not just to create code coverage but to force design improvement as the code is being written. This is why I call TDD and its best known principles and practices of applying it Executable Design. If you are not improving the design of the application then you are not doing Executable Design. You might be just adding tests.

Some of the principles I have found to help me in applying Executable Design effectively are (and most, if not all, of these are not something I came up with):

• Don’t write implementation code for your application without a failing unit test
• Separate unit tests from system and persistence tests. (as described in this previous blog entry)
• Create interfaces with integration points in a need-driven way (as described in this previous blog entry)
• Always start implementing from the outside in (such as in Behavior-Driven Development and as described in this previous blog entry)
• Mercilessly refactor the code you are working on to an acceptable design (the limits of which are described in this previous blog entry)
• Execute your full “unit test” suite as often as possible (as described in this previous blog entry)
• Use the “campground rules” of working in the code: “Leave the site in better shape than when you arrived”
• Create a working agreement that the whole team is willing to adhere to, not just what the coach or a few think is the “right” agreements to have.

Try these out on your own or with your team and see how they work for you. Modify as necessary and always look for improvements. There are many thought leaders in the Agile community that have written down important principles that may work for you and your team.

And finally, now that I have filled an entire blog post with “Executable Design” what do people think about the name? It has worked for me in the past to explain the basic nature of TDD so I will use it either way unless others have better names that I can steal?

Scrum is based on an empirical process control that focuses on inspecting the current state and adapting behavior to improve. This focus on continuous improvement through “inspect and adapt” is supported in the Scrum framework at 3 points in the process.

• 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 therefore 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.

The “inspect and adapt” focus allows for a Team and product to continually improve over time through seemingly simple mechanisms with sizable effects on the software delivered. An unexpected or additional effect of this focus on “inspect and adapt’ in Scrum is the organizational environment encompassing the team starts to adjust based on needs of the Team to improve their software delivery. Therefore a single team causes “organizational change” through small and incremental adjustments.

One of the main tools that a Scrum Team can use to “inspect and adapt” is the “impediment”. An impediment is:

“Anything that prevents a team member from performing work as efficiently as possible” – from Victor Szalvay’s article “Glossary of Scrum Terms”

In coaching teams I have found that capturing impediments is done casually and is not initially found to be as important as other activities the team is doing. Over time I have found a few simple “rules of thumb” for capturing impediments that have helped Scrum Teams:

• ScrumMasters keeping a physical impediment and action item list. As we teach in the Certified ScrumMaster course it is important to action impediments after the Daily Scrum meeting immediately. Many of our teams at SolutionsIQ setup an area to capture impediments written on post-it notes. Following the Daily Scrum meeting team members who are interested in taking action on the newly captured impediments stay behind to work with the ScrumMaster. An action item is created identifying “What” needs to be done, “Who” is going to make sure it happens, and “When” they will communicate progress back. It usually looks something like this:

Impediments getting actioned

• At least 1 impediment raised every Daily Scrum. It is my opinion that if a Scrum Team is unable to bring up at least 1 impediment at each Daily Scrum then the ScrumMaster is not supporting the team effectively. I want the ScrumMaster to find ways to extract at least 1 impediment during the Daily Scrum. In the past I have asked teams whether they were comfortable speaking about an impediment they are having in the Daily Scrum with me there. I have also pleaded with a team to tell me at least one impediment before we leave. One time the Daily Scrum was before a Sprint Review we were going to conduct in the afternoon. Each team member said they had no impediment and at the end I found out that at least one person was not ready to demo the software just by asking “Why are there no impediments today?”.
• Ask everybody on the team to write down at least 1 impediment. Sometimes a Scrum Team has improved significantly and begin to get into a flow. Although I want to celebrate significant improvements we should not sit on our laurels. The stagnation of “status quo” can catch hold quickly and we must find ways to break through this potential behavioral issue. Just ask all members of the team to write down at least 1 impediment and then work with the team to action those impediments immediately as shown above. One of my colleagues, Brent Barton, once wrote up on our white board the following saying that I have found to be helpful to me for fighting the “status quo”:

“The absence of conflict is not harmony, it’s apathy” – from article by Kathleen M. Eisenhardt, Jean L. Kahwajy, and L.J. Bourgeois III called “How Management Teams Can Have a Good Fight”

My own nature has helped me internalize the “inspect and adapt” mindset with Scrum. I used to think I was lazy but the fact that I would work additional hours to improve builds, mock frameworks, test cases, and other artifacts of projects I worked on seemed to contradict this. The reason I thought I was lazy was my tendancy to find ways to automate just about anything that could be so that I did not have to manually do it anymore. My initial splash into programming actually started this way while working in a data entry job. Each day my work was incredibly repetitive. One day a person who understood the software we were using to do data entry showed me the use of a cool macro that allowed fields to be automatically filled out. I was immediately impressed and asked them to show me how that worked. The language used was a Visual Basic knock off and the scripts I wrote following this allowed me to get 10 times faster in my data entry. I was able to focus on other activities including learning HTML, JavaScript, Pascal, and Java. The moral of this story is jump on opportunities to improve your environment including processes, facilities, and software.

Those additional hours I put in has decreased over time as I have found a much more sustainable pace for myself. I cannot say that I keep a fully sustainable pace even now but at least I am able to identify earlier when I am starting to tank. The “inspect and adapt” mindset should not cause our Scrum Team to adapt themselves into a culture of late hours and intravenous Red Bull drips. A Scrum Team should find ways to adjust within their timebox rather than adjust their timebox. This means that hourly, daily, and iteration timeboxes are important to understand and monitor for breakage. As a ScrumMaster I want the team to keep a constant pace as much as possible and sudden adjustments that cause time management problems should be identified immediately and monitored from there to resolution ASAP.

A continual need to improve my life and environment has become an addiction of mine. How can I better use the time I have with my family? How can I help make my work environment even more fun to work in? What can I do to improve my knowledge in all types of subjects? This addiction has been a valuable behavior for my entire life and I hope that others will find something that has similar effects for themselves. People reading this blog who are currently using Scrum please use the impediment to your advantage and find ways to improve your software delivery. It’ll be worth every minute used to “inspect and adapt” your Sprint, Product Backlog, and processes.