Feed aggregator

How It Works: User Stories

Rally Software - Agile Blog -

Next Tuesday, February 10, our TeamStart webinar series will answer your questions about "Writing Great User Stories." Whether you’re just getting started with Agile or consider yourself an expert, join us to get and give some good Q+A. We’re going to talk about writing compelling stories that focus on business value. Here are a few questions from past "User Stories" webinars:

  • What are some tips for writing a great user story?
  • When do I break down user stories?
  • Who should drive the definition of acceptance criteria?

Here's a preview of what you'll learn in the TeanStart webinar.

Tips for Writing a Great User Story

A great user story has three areas of focus: Who, What, and Why. A great user story is also written from the perspective of the user (hence the name); and a great user story "tells a story" about what that user wants to be able to do, and why (for what outcome.)

Who: Define the person who receives value from a new user story. For example:

As a user of the website ...
As an internal team member ...

What: Indicate what needs to be delivered, from the perspective of the user. For example:

... I want to purchase my items with a credit card ...
... I need a new testing infrastructure ...

Why: Show the value the user gains from the story:

... so that I have a convenient and secure way to pay electronically.
... so that I can prepare for the new test requirements of our organization.

When to Break Down User Stories

When the estimated size of a user story exceeds the total velocity available in a team’s iteration, the story cannot fit and must be broken down into smaller stories. User stories can be broken down multiple times as they move up the backlog -- transitioning from a large, loosely-defined, parent story into a set of small, defined, child user stories that make progress towards the overall goal.

Who Should Drive the Definition of Acceptance Criteria

The entire development team assists the product owner in creating acceptance criteria. Product owners represent the business and stakeholders, and communicate the needs of a story to the team. Teams communicate with the product owner about what implementation methods are possible, and how a story may be completed to meet business needs.  

What are your questions? Get them answered. Join the TeamStart webinar series on Tuesday, February 10th, to learn about "Writing Great User Stories."

Rob Ward

An Innovation in Scrum Ceremonies: Peer Feedback

Agile Connection -

Traditionally, the project manager or ScrumMaster is responsible for evaluating a team's performance. But peer feedback, when each member of a team picks another member, observes him or her, and then shares thoughts and suggestions about that other team member’s work, can also be very valuable to continuous improvement.

Agile is NOT For You

VersionOne Agile Management Blog -

Guest post from Daniel Gullo, Apple Brook Consulting

You are talking with two consultants about how to transform your organization into an Agile development company so that you can go faster and keep ahead of your competitors.

You explain to them that your stakeholders have a need to know what is going on and to that end, there are reports that need to be created. Furthermore, your product is governed by Sarbanes-Oxley controls, which absolutely MUST be followed. Funding for your projects is allocated two to three years in advance and is based on detailed estimates, which are in turn derived from the Work Breakdown Structure (WBS) for the project. None of this can change.

You continue to explain that the teams are geographically distributed across four continents and 10 time zones and that restructuring the teams and bringing the teams together, even just for release planning is not possible. Your organization also has no budget to buy things like webcams, additional monitors, team rooms, or even open wall space.

The ScrumMaster in your organization will be “in charge” of 10 to 15 teams and may have other responsibilities as well. Also, the “Product Owner” is really in charge of an entire business unit and won’t be writing any User Stories, so the business analysts will need to be a “Product Owner Proxy” for each team.

After spending 20 minutes relating all of this (and more) to the consultants, including how none of this is negotiable, you ask, “So, what are your thoughts on the best way to implement Agile development here?”

There is silence.

After what seems like an eternity, one of the consultants clears his throat and says “Agile development is NOT for you.”

Did you really just hear that??? Doesn’t this guy get it? Is he really so independently wealthy that he is going to throw away the money that is on the table??

There’s a saying that goes: “If you didn’t get the joke, then the joke was not for you.”

If your company is not open to change or trying new things or running experiments in order to learn, then, Agile is NOT for you.

If your organization is not interested in having happy employees by focusing on people or they aren’t willing to make an investment in tools or to look at simple measurements of customer satisfaction such as the Happiness metric or Net Promoter Score, then, Agile is NOT for you.

If you are not willing to explore what “possible” really means and thus, have an open mind to doing the unconventional, then, Agile is NOT for you.

I’m sorry. I really am.

Agile is not magic. We can’t produce something from nothing or make other trade-offs go away. In order to get X, then you must do Y. You can’t expect to maintain the status quo AND improve. It’s simply not the “real world.”

Agile is all about embracing the uncertainty of change and learning how to use it to your advantage.

As a consultant, I often test the waters a bit when going through the discovery stage with a new client. I might say something that represents a “worst case” scenario to see if they are prepared to go there if it comes to that. I also ask a lot of questions around seeing how they think about people, constraints, etc.

My educational background was in Law. I am inclined to look at possibilities. I often find myself in a workshop or training session orating as if I were in court:

“In your expert opinion as a Senior Software Developer, is it POSSIBLE that you could build production-ready features, albeit very small slivers, that are capable of functioning from end to end by cutting through the entire architecture?”

“No. We can’t produce anything of value in less than six weeks.”

“So, it’s NOT POSSIBLE to release a single field on a webpage with a submit button that applies some business logic and then inserts a value into a table in a database that only includes that field? That’s absolutely NOT POSSIBLE??”

“Um, well, yes.”

“I rest my case, your honor.”

Becoming Agile means being open to possibilities and options.

In a sense, BEING Agile is like acknowledging and understanding what innovation truly means in the same sense that an artist understands what “creativity” means. Is someone who simply slaps paint on a canvas with no understanding of what they are doing considered an “artist?” Most of us would say that they are not.

Likewise, I can explain the agile values, principles, practices, and dynamics of agile culture to someone, but I can’t tell them how to be innovative. That’s something that has to come from within.

It’s uncomfortable, change.

And, through discomfort, we learn and grow.

If you are comfortable with how everything is going, then you aren’t learning.

If you aren’t comfortable with the prospect that Agile is going to make you uncomfortable, then sorry; Agile is NOT for you…

Eight Simple Ways to Improve Distributed QA Teams

Agile Connection -

Geographically distributed QA teams and the challenges that they face are a common and ongoing topic in the software development world. In this article, Kevin Wilson focuses attention on eight simple solutions that can help maximize the effectiveness of your distributed QA team.


Scrum Log Jeff Sutherland -

Multitasking is a form of wasted motion. Taiichi Ohno, in his keystone book: The Toyota Production System outlined a total of 13 forms of waste. Multitasking is a classic form of Muda, or wasted effort. It happens when people, systems or machines switch between contexts. Context switching has been heavily researched and pretty much every study shows that it creates large amounts of waste (see slide.)

A scientist named Harold Pashler demonstrated this in the early 1990’s. He called it “Dual Task Interference.” Pashler theorized that there was some sort of processing bottleneck happening in a person’s brain when multi-tasking. That people can really only think about one thing at a time, that a certain amount of effort was involved in packing up one process, reaching into your memory and pulling out another, and then running that job. And each time you switch tasks, that process takes time. Numerous other studies show the same thing.

Weinberg - Context Switching Slide121

The lessons a Scrum Master should take from this is to make sure individual Team members are protected from distractions and other Impediments that would cause them to switch from one Backlog Item to another. Other research has shown that people typically work best in 90-minute bursts followed by some recuperation time. Scrum Masters should make sure to give their Team members ample opportunity to work in blocks of uninterrupted time but also make sure they have opportunities to take care day-to-day assignments that are just a part of having a job like filling out paper work and other management overhead.

Product Owners need to demonstrate to management that their Teams can do better quality work, faster if they can work on one project at a time. The business case for this is strong. Teams can get multiple projects done is less time when they can focus on just one project at a time. The quality of their work also increases. Just like switching from writing, to reading e-mail, to a phone-call interrupts, slows down and wastes an individual Team member’s time, switching from one development project to another wastes Team time (see slide.)

Multitasking is an embedded part of our culture in the digital age. Job descriptions demand it, bosses expect and we brag about our abilities to perform it. It seems like as a society, as multi-tasking has been pushed more and more upon us, we have embraced it. Unfortunately, multi-tasking is wasteful. Don’t do it.

Back to All Topics

The post Multi-Tasking appeared first on Scrum Inc..

Scrum Inc. Heads Back to the Valley

Scrum Log Jeff Sutherland -

This past fall I visited some of the biggest tech players in Silicon Valley (PayPal, Twitter, Salesforce, Wallmart.com etc.) There were two take-a-ways from those visits. First, people, mostly leadership, wanted to know how to scale their Scrum implementations; and second, teams weren’t getting testing done inside the Sprint.

I’m heading back to the Valley in mid February to teach both a public CSM and CSPO course as well as a one day Scaling workshop and I plan to address these two issues head on.

Scaling: More scaling frameworks come-online everyday. Most I find overly prescriptive and limited in their efficacy. However, frameworks like SAFe are a good starting place for companies with very new implementations.

It’s important to remember that Scrum was designed to scale. The first time I scaled Scrum teams at IDX in the mid 90’s it became really clear. Scrum is based on modular or object oriented architecture. It allows multiple teams to swarm on all modules simultaneously without ripple effect. This is called all-at-once-Scrum and it was the team model Nonaka and Tachieuchi highlighted in their HBR paper that inspired Scrum. A truly effective Enterprise Scrum should be modular in design. The Scrum Inc. team has developed a scaled framework that allows companies to plug-and-pull the modules they need based on their specific context.

What is your context? Are you in a large mature industry like a government contractor? Or, are you a successful software company feeling innovation nipping at your heels? Depending on your vision, needs and industry, you will probably want to prioritize certain scaling aspects before others.

Test Inside the Sprint: Quite possibly the most important aspect of Scrum is the feedback loop. The team demonstrates working software to all the stakeholders at the end of the Sprint. The stakeholders try it out and then give the team feedback on possible improvements. Continuous improvement is really the end game here so without working software, the Scrum process breaks down.

It has to work to get feedback. You won’t know it works until you test it.

If you aren’t testing inside the Sprint, you don’t get feedback from your customers and stakeholders at Sprint Review. Feedback you need to assess what they like, what they don’t, and make changes early.

Testing is tough and a lot of teams don’t feel like they have the skill set or the opportunity to test within the Sprint. Bring you testers onto the team. Use out-of-the-box tools and develop a testing regime incrementally. With clear goals and a motivated and focused team, testing can get done before review.

-- Jeff Sutherland

The post Scrum Inc. Heads Back to the Valley appeared first on Scrum Inc..

How Rally Flowdock Does Support

Rally Software - Agile Blog -

On the Rally Flowdock team, everyone does customer support. We don’t have dedicated support people. The people who respond to support@flowdock.com are the ones who develop, market and lead Flowdock. This is surprising for many. We often receive requests to “pass this message on to the development team”.

Shouldn’t a software developer spend their time building a better service, not handling customer support? More generally, shouldn’t people spend their time on what they were hired to do, and not waste time doing support? These are common thoughts that lead to the creation of dedicated support teams, outsourcing customer support. We find this to be a detrimental, even dangerous practice. Having the whole team do support is crucially important for many reasons, outlined below.

Feel for Your Users

Increased empathy for your users is the most obvious benefit. There’s no better way to understand users than by having a constant line of communication open with them. Even if you dogfood your own product (as we do, heavily), you’re still looking at it from one perspective. What seems like a minor bug may be extraordinarily frustrating for some, while a small new feature can be tremendously beneficial for others.

Having the whole team interact with customers leads to a surprising benefit: a shared understanding. We rarely have disagreements about what we should work on next – the team simply knows which features will provide the most benefit for our users.

Communicate with the Ones Responsible

When you’re solving a problem with a user, you often have to dig into parts of the product that you aren’t familiar with. You might have intricate knowledge about how your product’s integrations work, but be clueless about the signup process. When you start helping a user who is having problems signing up, you force yourself to expand your expertise. This leads to everyone on the team having a better understanding of the product as a whole.

This is great for users as well. When they have an issue, the foremost experts on the product – the people who designed, built and thoroughly understand it – are the ones answering. Instead of having to look for answers or delegate problems (aka. handovers, see below), the responder often provides a knowledgeable answer, quickly. And if not, they can ask for help in the team’s flow.

We’ve received lots of positive feedback about our customer support. Users appreciate being able to talk to the ones responsible for a product.

Chat as a Bug-tracking System

Unless a lot of effort is spent grooming its contents, the value of a formal bug tracking system decreases over time. The volume of bugs that are no longer relevant grows gradually, making it harder to pick out the important ones.

Our current process for handling bugs is lightweight while still ensuring that important and easy bugfixes get delivered. When we encounter a new bug, a quick triage takes place. If the severity is high, it’s fixed as soon as possible. The bug is reported in our flow with a#bug tag and a @mention of the person who has agreed to fix it. Once fixed, the #bug tag is removed. Low severity bugs with trivial fixes are fixed right away, while the rest of them are mentioned in our flow. If a low severity bug starts affecting many of our users, we will see more mentions of it, increasing its severity.

Because the development team handles support, this type of lightweight bug handling is possible. Customer support is an important input when assessing the severity of bugs – important bugs will rear their head via support messages.

Handovers Suck

Finally, not having a dedicated support team removes at least one handover. When a support person handles a case by escalating it to a developer or team, they can (correctly) feel that they’ve done their part without actually resolving anything. This is in no way the fault of the support person – they’re acting as they should. But it’s an indicator of a badly designed system.

If you design your customer support system to include handovers – points at which responsibility is absolved – you’re setting users up for disappointment. In addition to delaying resolutions, each handover throws away the rapport that was painstakingly built between a user and a support person.

There are, of course, situations when a handover is necessary. An example is when a team member is unable to fix a reported bug by themselves. We’ve tried tackling this by making the original responder responsible for finding the person to take over the problem – hence the @mention that gets added to the bug report in our flow.

Scaling Support Without a Support Team

Since our user base grows at a faster rate than the Flowdock team, this presents a problem: will we be spending too much time handling support at some point? We could hire people to take care of the so-called level 1 support cases.

Unfortunately, this might take away most of the benefits outlined above. Easy support cases are our background hum. They don’t take up a lot of the team’s time and effort, yet provide us with valuable insight into our users: what aspects of Flowdock they love and which features are causing confusion.

We haven’t come up with a silver bullet solution for this challenge. The end result will most likely be some sort of hybrid approach, with the Flowdock team still continuing to handle support. In addition to scaling support, having dedicated level 1 support people does provide a few other benefits: easy issues are handled quickly, on all time zones.

For now, we will continue handling support ourselves while building a user-friendly service that is as bug-free as possible, minimizing tricky support requests. When the scalability of our support becomes an issue and forces us to evolve our process, we’ll be sure to share the outcome on our blog.

Flowdock team members in snowy Helsinki

This post originally appeared at the Flowdock blog.

Ville Saarinen

Always Read the Label: Getting the Most from Your Tools

Agile Connection -

It is possible to find a new, innovative use for a tool, but it’s much more likely that you’ll do better using the tool in the way its creators intended. And whenever you reach for a tool, check that it’s actually going to help solve the challenge you’re facing. This article explains why first and foremost, conversation is more important than a shiny new tool.

The ‘Agile Playbook’

VersionOne Agile Management Blog -

Football players spend a lot of time studying their Playbooks. And Coaches spend a lot of time creating and updating them. These guys are serious. The stakes are high in the NFL; millions of people are watching. Their stated goal is the same each week; to win. That means they gotta work really well together and know what they’re doing.

I think the game of American football is a great example to follow as an Agile team in the corporate world. We all need some help with remembering stuff, and getting it down so we can execute on game day. Even if we’ve done it many times before, it’s easy to get forget; there’s just so much to know and remember. This is hard stuff we’re doing, and it’s in constant flux. We often find ourselves wanting someplace to go for reference, clarification, advice, dare I say… ‘best practices.’

I’ve had several clients (both large and small) ask me for something they could use to document the way they ‘do Agile.’ If they’re new to the game, often they will look to a consultant or Agile Coach to guide them or help create this information.

Enter ‘The Agile Playbook.’

So what is an ‘Agile Playbook,’ anyway?

In short, it’s a helpful guide. It can come in many forms. For now, let’s stick with the football analogy. If you’ve watched an NFL game recently, you’ve probably seen the coach holding up a play sheet, as he decides what play to call. If you (or your kid) has an XBOX or PlayStation with Madden NFL, you know it has a Playbook feature built into it. Note: this could be an interesting feature opportunity for Agile Lifecycle Management (ALM) tool providers, huh? But I digress. So, as for the Playbook itself, I think of this as the larger, over-arching deliverable.

Transferring this idea of an NFL Playbook into the world of Agile software development is natural. I’ve heard it referred to by different folks in similar ways, like ‘Agile one-stop shopping’, or an ‘Agile Coach in a Box’, or ‘How we do Agile here at Company XYZ’. I personally like the term ‘Agile Playbook’ because it’s short, simple, descriptive, and I believe it drives home the team concept nicely.

Who wants an Agile Playbook?

Can you imagine an NFL team without an organized list of plays? So why would we think it’d be any different in our Agile organizations? I remember playing pickup football and we’d draw pictures in the dirt of what we wanted to do. That was fine for a pickup game, but even my nine-year-old son’s flag football team has a playbook. So the question of ‘Who wants it?’ is an appropriate one. If we think of Mike Cohn’s user story template (As a ___, I want to ___, so I can ___), this is the ‘As a’ piece. Who are we doing this for, anyway? Is it the PMO Director? The ScrumMasters? Product Owners? The Team? Program and Portfolio Management? Executives? The answer, in my six years of personal Agile consulting experience, is ‘all the above.’ If they don’t ask about this at some point, it’s usually because they haven’t thought about it yet.

Why do they want an Agile Playbook?

Hopefully, because it adds value. This is the ‘So I can’ part of the story. It’s a guide to help them get where they want to go. It’s something we can point to when someone asks, “How are we doing Agile in our organization?” It’s something we can go to for reference when nobody else is around. It can even be used as an onboarding tool.

The Agile Playbook also gets us thinking not only about how we work, but how we can improve our processes. Are we really being empirical? Give it a little love in your retrospectives. Perhaps there’s an opportunity to update the Playbook. Oh, and if by chance you don’t see any value in it, simply don’t do it.

Yes, it’s a document.

OK, I know what many of you must be thinking by now… The Agile Manifesto says ‘Working software over comprehensive documentation.’ Yes, an Agile Playbook is a document. And yes, it’s likely to be pretty comprehensive. But that’s a relative term; more specifics on this will follow in a bit. The Agile Manifesto doesn’t say documents are evil. In this case, I believe it’s a very helpful and necessary document to have available in order to get everyone on the same page, and to show auditors that our processes are documented (they like that kinda stuff, ya know). An Agile Playbook is a big deliverable. It takes a lot of time, effort and know-how to put something like this together.

When I did one for a client a couple years ago, we employed a full-time Tech Writer for about a month. That was a huge help. I had initially tried to do it on my own, in my spare time, but that didn’t work out too well. The folks in the Agile PMO, including myself, provided the content, primarily.

But I’ve seen other organizations go with almost nothing documented, just pulling in a coach or two and letting it roll. Maybe sharing a few slide decks on an internal page. No strong desire to document the why, when and how we do stuff. I wonder if that’s because they hadn’t thought about it, didn’t want it by design, or just didn’t have the bandwidth. Or maybe there were other reasons. Personally, I believe that not documenting something this important to the agile transformation of your organization is irresponsible.

And having it documented – but all over the place in different formats – can be chaotic. I don’t like to make people go hunt down stuff, let alone guess or assume anything.

My opinion is that this should be as close to one document (or series of web pages) as possible, not multiples; i.e., not nine Powerpoint slide decks, seven Excel spreadsheets, and 12 Word documents with a bunch of buried links to even more documents, slide decks and spreadsheets. Make it as simple as possible. It’s one place to go. One thing to print off (if you desire to have a hard copy) and carry with you for reference. One URL to save as a favorite.

It can help us realize gaps in the way we work.

What I learned early on is that the hard work of creating an Agile Playbook forces us to give a long, hard look at the way we’re working now, and how we want to work in the future. It’s cathartic. It helps us identify areas where we can improve our processes. It forces us to ask some difficult questions. And make some difficult decisions.

One way in which to identify areas of improvement around your process is to identify your value streams. This is a basic Lean principle. I’m sure we’ve all done something like this. How efficient are we in going from start to finish (request to deployment, concept to cash)? Our goal should be to optimize this. Look to reduce delays, inefficiencies, and improve our cycle time.

How do we document tools and technical practices?

Let’s not forget how our tools and technical practices play into this, as they’re an important factor in how we get work done. If your organization is using an Agile Lifecycle Management tool, the Agile Playbook might include best practices on how to use that as well – either melded throughout, or as a separate section.

Same goes for development tools that help us with…

– Continuous integration – Jenkins, Hudson
– Defect Management – Bugzilla, JIRA, HP Quality Center
– Integrated Development Environment – Eclipse, Visual Studio
– Test Management – HP Quality Center
– Source Code Management – Git, Subversion
Agile Portfolio and Project Management – VersionOne, et al.

This can be a lot of information, so when documenting for the Agile Playbook, this is an area where I make heavy use of links to information beyond the basics of each of the tools we use.

It should be comprehensive, yet brief.

If you can’t fit the Agile Playbook into your front pocket comfortably, it’s probably too big. When I say brief, I mean about under 50 pages for a large organization. Any more than that, I think folks begin to feel overwhelmed and push it away. Any less, and it’s hard to be comprehensive. There’s no science behind that decision, but if I apply my own average attention span to the matter, this sounds about right. I think much of this also depends on the format you use: Microsoft Word, Powerpoint, HTML, etc. Again, where appropriate, I like to make liberal use of links to other documents/sources to help minimize the length. I recommend placing it on a well-known organizational site such as Wiki, Sharepoint, etc. Provide a highly visible and pronounced link from your internal company home page, and give the option of printing out a hard copy. In fact, I like to have several hard copies available in the Agile PMO to hand out to folks who want one. You’d be surprised how quickly they go. I’ve found that a nice ringed binder works best. That way, if there are changes, you can swap out a page or two. That said…

Did you know…

Most NFL teams now use tablets (iPad or Surface) almost exclusively for their Team Playbooks?

If you’ve watched ‘Hard Knocks’ on HBO, you already know that the phrase “Turn in Your iPads” has started replacing “Turn in Your Playbooks” when players are cut from an NFL team. Those teams have discovered that the technology goes far beyond the old playbook capabilities. There’s a product called ‘PlayerLync,’ which is at the forefront of this movement. It has revolutionized the way teams push out film and significantly altered the way they communicate. Beyond saving printing costs, digital playbooks are improving the effective, real-time communication by allowing coaches and quarterbacks to add and share plays with the click of a button. Every time new data, film or information is added, a banner alert pops up (like a text message), signaling players to view the updates.

Oh, and PlayerLync isn’t just for professional sports teams. Here’s a short clip on how Chipotle and others are using it to push content to their teams:


Uniqueness and commonalities

I’ve helped put together a number of these Agile Playbooks for different clients now, and each was both unique. But there are many commonalities, like the general Agile principles and practices. At the end of the day, folks want to know what to do, who does it, when to do it, and why. All these things can be exclusive to the organization or industry. The extent to which Scrum, Lean, and XP practices are applied also varies from company to company.


The fear seems to be centered around teams in an organization that are using both the framework and the tools differently. It could be that we’re not all using the Agile Lifecycle Management tool in the same way. How in the world can we expect to have rolled up views into the different management levels (Portfolio, Program, and Project) without a common agile project management tool? This opens the door to confusion on many levels, especially when we start talking about agile metrics/reports. But it’s not just the management level that has a problem if we’re not all on the same page. The individual team members also experience fear… fear of doing the wrong thing, or doing it incorrectly, getting called to the carpet or, worse yet, being publicly shamed, written up, or fired. The idea is that if we’re all on the same page, and everyone knows what’s expected, this fear diminishes greatly. Life gets better for everyone.

Start with an outline…

Finally, you were probably wondering when I was going to get here. By the way, each organization’s Agile Playbook is their own. I cannot share the exact Playbooks that I’ve put together with clients, as that information is proprietary. But I can share with you a more generic outline of what an Agile Playbook might look like:

About the Agile Playbook
What is Agile and Scrum?
Implementing Agile and Scrum at Company XYZ
Essentials of Agile and Scrum at Company XYZ (How ‘We’ Do It)
Agile Planning
Agile Execution
Agile Cultivation
Agile Tools
Agile Reporting/Agile Metrics
Staying Compliant with Agile
Company XYZ Communities of Practice (COP)

Do you have a Playbook for how you ‘do Agile’ in your organization? If so, what does it look like? If not, why?

Retired Rally Laptops Find New, Happy Homes

Rally Software - Agile Blog -

At Rally, we love our Apple laptops. Typically we use them day in and day out for three years or more, after which they enjoy their next phase of life.

In 2014, we started a donation program to place them into good use at “retirement homes”—organizations that would appreciate them until their useful life is over. Through the course of last year, we donated 95 MacBooks valued at nearly $30,000 to Colorado nonprofits and educational institutions. I’m happy to share a few of their stories.

Boulder Emergency Squad

At Rally, Cliff Rosell is a Senior Financial Analyst; but at Boulder Emergency Squad (BES) he’s a professional rescuer, IT supervisor, Resource Planning Supervisor, and Board Member —roles that add up to about 1,000 annual volunteer hours.

In 2014, Rally donated two iMacs and three MacBook Pros to support the work of this life-saving community organization. According to Cliff, “Prior to Rally’s donation, we had one desktop computer. Now we’ve upgraded our radio dispatch computer, have a dedicated system for training presentations, enabled two officers to work remotely, and have added a dedicated laptop for any member to use. Rally’s donation has really helped modernize BES in a way that could not have been done otherwise.”

Boulder Emergency Squad volunteer Nicolas Venot looks at map and call data on the donated computer used for radio dispatch at the organization’s headquarters

Brighton High School

Rally IT Director Jesse Brouillette spends his 1% paid volunteer time helping out at Brighton High School (BHS), where he uses his technology skills and expertise to help the small IT staff. The school has two computer labs but that need to serve nearly 2,000 students, so access to technology is limited.

Jesse and his wife, Emerald—who is Dean of Students at BHS—brainstormed affordable and feasible ways to increase technology access at the school, and decided to build a self-contained mobile lab that could be wheeled into classrooms. Rally donated 42 retired laptops for the project, and this mobile cart how now effectively doubled the computers available for student use.

Jesse Brouillette (right), Rally’s IT Director, volunteers at Brighton High School’s IT department and helped create a mobile lab with Rally-donated laptops.

In recognition of the contribution, Rally was honored with the school district’s “Reaching In” award, given to a business or other organization from the community that makes a significant impact.

Open Media Foundation

The Open Media Foundation (OMF) is an innovative media and technology nonprofit dedicated to putting the power of the media in the hands of the people, enabling everyone to engage in their community and bring about the change they wish to see in the world. OMF accomplishes its mission by providing access to affordable, high-end media and technology services. The staff and volunteers offer training and tools that enable everyone to represent their own voice in the media conversation.

With 10 laptops Rally donated in September, OMF was able to begin offering members of Denver Open Media (DOM) the ability to work on projects remotely. Explains Liz Wuster, Member and Donor Relations Manager, “In fewer than 60 days, the laptops have been checked out 34 times, for a total of 2,591 hours! They have been used individually by our members, and in bulk by organizations, such as the Denver Film Society, in its efforts to teach editing and animation to youths. We offers classes around tech capacity and editing, which give our members a better grasp of how to most effectively use these laptops.”

“The MacBooks donated by Rally have been very useful in terms of doing edit jobs on Adobe Premiere and making graphics on Adobe Photoshop. They've allowed me to get things done in the video production department when I can't come in to Denver Open Media during office hours.” - Brian Nemeth, a DOM member

I Have a Dream Foundation of Boulder County

ln October, the I Have a Dream Foundation of Boulder County (IHAD) put 10 Rally-donated MacBook Pros to immediate good use. Each year, the organization selects a cohort of 50-60 low-income “Dreamers,” at-risk kids who are partnered with community members. These Dreamers are encouraged in elementary school to believe that college is an attainable goal, and as they grow up they receive extensive career and college preparation guidance, sponsored campus visits, and assistance with the application process.

The Dreamer students are using the laptops to complete coursework, projects, and internships as they prepare to enter college. IHAD staff members use the laptops to raise needed funds for programs through grant writing, as well as to recruit, interview, and train tutors and mentors. IHAD’s program director will use her laptop to manage the caseload for 60 new Dreamers—tracking attendance, grades, and case notes as they begin their journey toward high school graduation.

“Before this MacBook, I didn't have access to a laptop in order to conduct off-site volunteer recruitment presentations, interviews, and trainings. I am very grateful for the new laptop from Rally!” commented Ashley, Volunteer Director at I Have a Dream Foundation

We’re delighted to hear the stories of how our “old” laptops are helping others in their next stage of life. We now have more requests than we can fulfill, so 2015 is likely to be another busy year for Rally laptops to find new, happy homes.

Geri Mitchell-Brown

Quality Assurance Is a Process, Not a Department

Agile Connection -

QA is often considered that lonely department of testers whose job is to find defects before the customer does. It's not always glamorous, but QA deserves to be recognized as a key cog in the testing  machine. To achieve business goals, it is Susan Bradley's view that the QA process needs to be embraced throughout the entire software development lifecycle.

Guide Your Agile Development with Traceable Tests

Agile Connection -

Testing professionals who are learning about agile often want to know how they can provide traceability among automated tests, features, and bugs and report on their testing progress. Here, Lisa Crispin gives an example of how her previous team worked together to integrate testing with coding and helped everyone see testing progress at a glance.

Pair Programming

Scrum Alliance -

Pair programming? Two people staring at one PC screen, using one keyboard and one mouse? Why would companies hire two individuals to work on the same thing?

The Psychology of Agile

Scrum Alliance -

When we analyze traditional Waterfall application development projects post-release, it is easy to see that, not too long into the development life cycle, team productivity plateaus and eventually declines. Agile works differently. . . .

New Features for Speed, Visibility, and Scale

Rally Software - Agile Blog -

Scaling Agile is all about coordinating work across development teams and aligning that work to your top business priorities—so you can deliver value to customers. If you’ve got Agile programs spanning multiple development teams across multiple sites, it’s imperative that you have tools to help you manage the complexities of working collaboratively at scale. Over the past few months, Rally has introduced several new features to help you do just that.  


In November Rally launched milestones, which allow you to connect your most important development work to the critical deadlines, events, or releases your business needs to hit. With milestones you can link stories, features, or whole releases to a particular date: a market event, a trade show, or an important code deployment. Since the value of whatever you build doesn’t count until it reaches the customer, being able to plan and track your work against key events like this helps you steer your development to critical business goals.

Portfolio Item Dependencies

In December Rally introduced portfolio item dependencies, giving you the ability to plan for and manage critical dependencies among your features and releases.  

To build and execute on realistic release plans, you’ve got to account for feature-level dependencies across development teams—work that must get done before a feature can be completed. For example, you might have specialized teams building pivotal, individual components for a feature; or you might have several features that all contribute to the marketability or readiness of a major release. Now you can create, assign, view, edit, or delete portfolio item dependency relationships for any portfolio item from the new portfolio item editable detail page (in beta.)

The ability to see dependencies is especially powerful during collaborative release planning events (for example, big room planning) because it encourages cross-team conversations that mitigate risks, foster commitment, and yield a successful plan for completing development work.

During development, the ability to visualize both story-level and portfolio-level dependencies also helps teams understand when work they depend on is ready (predecessors) or when their work is needed (successors.) This allows them to plan their iterations more effectively, and fosters collaboration between teams so they can resolve bottlenecks in a timely way.  

Hierarchical Portfolio Items Page

Rally also has introduced a new hierarchical portfolio items page (currently in beta) that shows you how stories connect to their parent features, and how these features in turn connect to the key business initiatives to which they contribute value—all in one hierarchical view.  

This rolled-up, simplified view has benefits to everyone involved in a scaled Agile program. Here's how:

  • Agile development teams understand the business reasons behind their user stories by seeing how they connect to features, initiatives, and higher-level portfolio investments. This helps teams feel like they have skin in the game for delivering value to the business, and helps them minimize waste by keeping their focus and resources aligned.

  • PMOs and engineering leaders get an aggregated, high-level status view from which they can quickly identify problem areas, drill down to see the features that are causing bottlenecks, and steer to a successful resolution.

  • PMOs and business leaders can assess the level of investment in key portfolio priorities—and actively adjust priorities and resources for the most profitable direction—by seeing full traceability from the portfolio level to the development task level.

New Task Board

We’ve given the task board in Rally an entirely new look and powerful new features to help you plan and manage your daily work faster and easier. This new task board view lets you add new tasks and user stories, view and edit fields directly in tasks, and use advanced filtering capabilties to view only the specific tasks you care about.

Custom Board

The App Catalog now includes a custom board that lets you visualize your data the way you want it. Do you want to see a feature Kanban organized by initiative swimlanes, or features grouped by milestones? Do you want to create Kanban boards based on custom fields? Rally’s new custom board is easily configurable so you can build exactly what you need. Just select the work item type you'd like to see, specify the information type to be displayed in the board’s rows and columns (from fields like milestone, owner, state, priority, etc..,) and select which fields to display on the board. From there, you can leverage your custom view boards to quickly edit values.

Eclipse with SSO

More and more companies are adopting single sign on, or SSO, to ensure secure access to all the key software systems they use while simplifying login procedures for their users. Along with Rally’s Visual Studio IDE plugin, our popular Eclipse IDE plugin now supports SSO. These plugins are used by developers to view or update stories, tasks, and defects without having to leave the IDE, providing context for their work and simplifying their workflow. Companies that require SSO can now take advantage of the integration these IDE plugins provide without the administrative overhead of managing a whitelist.

We look forward to hearing how these new Rally features help you plan, track, and deliver on your Agile programs! Get help with using these features at the Rally Help site, or contact your Technical Account Manager (TAM) to learn more.

Steve Wolfe

My Life as an External Agile Coach (Part 3 of 3)

VersionOne Agile Management Blog -

Here’s the last article in a three-part series from Susan Evans. As we ring in the New Year, this post describes a day in Susan’s life as a Product and Agile Consultant for VersionOne with various client engagements, travel and a family at home.

[Back to Part 1: “99 Problems But Coach Ain’t One”]

[Back to Part 2: “My Time to Evolve as an Agile Coach”]

Working for VersionOne as a Product and Agile Consultant has been a dream come true. All of my Job Satisfaction Acceptance Criteria have been met, and I couldn’t be happier.

Being an agile consultant and traveling for my job were new concepts to me, so thankfully I had the opportunity to shadow some talented individuals to help get my feet wet, show me the ropes, and build my confidence. I’ve experienced agile failing fast, but I’ve also experienced lots of inspecting and adapting that lead to success.

As an agile consultant, I have the chance to share my knowledge and experience with the goal of steering clients away from failure and closer to success. What I love is that I get to help clients in a variety of ways so I’ll never get bored. No two engagements are the same with different clients and their unique cultures, different cities in different seasons, and all of the lively individuals I meet. I’ve been fortunate to work with clients by learning their process and helping to configure and implement the VersionOne agile lifecycle management (ALM) software platform to enhance their agile practices. It’s a great coaching opportunity and a chance to gain insight into how different companies operate.

I also have engagements where I train people who are new to VersionOne, or want advanced training. Both are very satisfying because I get to help people be more proficient with VersionOne, making their agile process that much smoother. I’ve also had the privilege to guide clients through their agile transformation. It’s so rewarding to have people repeat your words back to you and truly be excited to try something new.

Image credit:  foxnews.com

All of those different clients in different cities means that I’ve slowly become a frequent ‘traveler snob’ and can relate to George Clooney’s character in the movie ‘Up in the Air.’ Being that I live in Atlanta and have Delta as a hub at Hartsfield International Airport, the nonstop flights have been great. All other airports and hotels look the same and I complain when I have to take a shuttle to the rental car, or if my room doesn’t have a mini fridge. When I get settled, I take full advantage of being in a new city. I’m an adventurous person and have really enjoyed the travel. I like to explore the touristy areas and have dinner with the locals. I was afraid that I would be lonely, but surprisingly am enjoying my alone time and it’s easy to make friends when I want some company. And my family is just a Facetime away so I can share my adventures with them, too.

I have two children in elementary school, so I was skeptical about traveling and missing out. However, my engagements are typically two to three days during the week with the occasional Monday through Friday. I’m able to block out important dates such as birthdays and recitals to ensure that I’m home.  Thanks to modern technology, I’m able to easily stay in touch with my family. My daughter likes to see my hotel rooms and my son likes to make silly faces at me. I’m still able to talk with them about schoolwork, their friends, and extracurricular activities.

I wouldn’t have been able to pursue this career if it weren’t for my very supportive husband, who also works and does a great job of holding down the fort while I’m on the road. I’m thankful beyond measure. I’ve gained so much experience and knowledge but I still have so much more to learn. Thankfully, I have an amazing network of agile coaches from which to learn and an active community to speak with and listen to. The fun is just beginning and I can’t wait to see what’s around the corner!




Being Agile, Even if My Organization Isn't

Agile Connection -

Many of us work for organizations that claim adherence to agility, yet in practice aren't even close. Agile is definitely here to stay, and if you haven't caught the wave, it is only a matter of time before you do. Brian Rabon  presents insightful techniques that can help you become more agile now.


Subscribe to Torak - Agile Scrum Kanban Coaching Training Phoenix AZ aggregator