[Agile Guide] – Agile User Stories and Estimating Spikes

“A Spike is a time-boxed piece of work who’s goal it is to answer a difficult technical question SO THAT the developers can properly illuminate a User Story or Epic.  By illuminate I mean; the ability to estimate those User Stories or break down Epics into estimated User Stories.  There should be no other real purpose.” – John Haro

John recently wrote a quick and dirty guide to dealing with Spikes when it comes to using them to elicit more detail for user stories. We liked how he described them:

  • Spikes should be used sparingly.
  • Spikes should be short.
  • Spikes should be driven by actual User Story needs.

So, per John, why shouldn’t we estimate Spikes when it comes to taking up development time?

  1. Completing a spike does not directly create working software so it does not directly deliver value to the customer.
  2. Given that a spike is not about delivering  actual customer value (completing a User Story) then it should not be estimated in Story Points.
  3. Story points are how we broadly estimate, and communicate size and complexity to the business.

If you estimate Spikes with story points and the customer or business sees that you’ve done X-number of points in an iteration with nothing to show for it… well that just goes against one of the principles of the Agile Manifesto: Working software as the primary measure for success.

Thanks a lot John for this great write up!

[HT: John Haro]

[Agile Guide] – Agile Business Intelligence – Why Agile Works with BI

As the need for business intelligence grows, companies need ways to make smarter decisions based on historical, current, and predictive data. Business intelligence (BI) isn’t just reporting. Better business intelligence is better decision-making. Sometimes called a decision support system (DSS), the way BI systems are built can have major impacts on the way a business moves and adjusts to demanding market conditions.

Sounds like serious business? Yes, it can be.

Sean McClowry tells us that it is about time for Agile BI to take the stage-front. Since Agile prides itself in collaboration, frequent releases, accommodating change, and relentlessly managing scope, it just makes sense that as BI becomes more important to businesses, an Agile approach should be the way to go.

“BI professionals have long been advocates of 90-day increments… However, incremental isn’t agile no matter how short the increments or how fast the iterations. The agile difference is in participation and interaction–not just building things quickly, but building the right things quickly. The participative model of agile brings with it the promise of breaking away from the “just another report” syndrome that plagues virtually every BI team.” – Sean McClowry

So how does Agile BI work?

Continue reading “[Agile Guide] – Agile Business Intelligence – Why Agile Works with BI”

[Agile Guide] – Agile for Technical Writers

We don’t often hear about the trials and tribulations of a technical writer. Frankly, that’s a space that may need more bloggers like Giri from IWorkAsATechnicalWriter.com to provide more valuable free content for other professional technical writers.

In Scrum, for example, we only really hear about three main players: The Scrum Team, the Product Owner, and the ScrumMaster. What about other players? In some businesses, technical writers are crucial to the entire process as they design, write, create, maintain, and update technical documentation.

What is interesting here is that there is a larger idea at stake: The idea of documentation for companies that run their businesses in an Agile manner.

Ever work for the government or DoD? What’s that documentation process look like? Doing Agile on a major security project that needs tons of documentation on development for audit reasons? Ah, the list can go on and on.

So how in the heck do you update and maintain technical documentation in an Agile environment when everything is subject to change?

Continue reading “[Agile Guide] – Agile for Technical Writers”

[Agile Guide] – Implementing Scrum and 3 Potential Blockers

Implementing Scrum with a new team can be a daunting task. In most cases, it can be something that is looked down upon, seen as something unnecessary or added-work. We’ve already covered overcoming fears and ego in an Agile transformation and the Coach’s role here.

Our first thoughts around this is that there may have been a gap in communicating the true value of going Scrum. Debbie Nichols says that there are three main ways that teams receive Scrum backlash:

  1. Adapting to a New Process
  2. Hating the Daily Scrum
  3. Estimation Tasks are a Nightmare

Debbie goes on to say that teams “Can, and should, adjust Scrum to meet both the needs and temperaments of their members.” I know of certain individuals that may balk at this and say it isn’t Scrum at all if some of the very fine-tuned aspects of Scrum aren’t participated in. Whether you’re on one side of the fence or another, it’s worth looking at Debbie’s blockers.

Continue reading “[Agile Guide] – Implementing Scrum and 3 Potential Blockers”

[Agile Guide] – Story Mapping for Scrum


  • You have a backlog full of stories.
  • You have a set of prioritized features that need to go out with your next release.
  • You are in need of a simple and quick way of viewing dependencies between stories and mapping features and tasks to their corresponding stories.

How can you easily connect the dots? With a story map.

Story maps are a great way to organize your backlog into a logical units for development. Karen Greaves has outlined a very simply way for you to build a story map and get back to workin’!

Her outline simplified:

Continue reading “[Agile Guide] – Story Mapping for Scrum”

[Agile Guide] – Rotating Responsibility for Scrums and Retrospectives

For those ScrumMasters who have started a new job or worked with a new client, taking the reigns and leading some of the standard meetings can be a challenge.

Hopefully there are only positive stories to go around, but sometimes a new ScrumMaster enters into a team that has been well established and set in its ways. Sometimes, a team has no idea what a daily Scrum meeting or Retrospective Meeting is.

A quick reminder of the Daily Scrum:

  1. About 15 minutes
  2. Everyone stands
  3. Everyone shares three things: What they accomplished yesterday. What they will work on today. Any blockers or impediments they have.
  4. Only developers and people involved with development may speak.
  5. Product Owners and other Stakeholders can stay silent.

A quick reminder of a Retrospective Meeting:

Continue reading “[Agile Guide] – Rotating Responsibility for Scrums and Retrospectives”

[Agile Guide] – Writing Good User Stories

This past month has been a good month to review what makes up a good user story. Several bloggers have posted on this topic and the Agile Scout has put together two of the best and decomposed them here.

Karen Greaves (@karen_greaves) has written about breaking down user stories and gives the reader a very simplistic view of the components of a user story. Interestingly enough to us, it was almost deja-vu-like to read her blog because it looked exactly like how we have broken down user stories for our clients!

Roman Pichler (@romanpichler) wrote previously about what makes up a good user story and 10 great tips on the small nuances of making sure your user story is in top notch shape for developer consumption. What we like most about Roman’s advice is that he suggests that people use paper cards (Oh no! Not a tool?!). Yes paper cards. Call us old fashioned, but we still believe in the tangible card and a big wall to post stuff on. But if you’d like to see the biggest list of Agile tools out there, you can always go here.

Recently, Zubair Ahmed (@zubairdotnet) wrote a post on how to gather Agile requirements through stories. Starting with the questions: “What is a story,” and moving into his observations from a presentation by Mike Cohn.

Continue reading “[Agile Guide] – Writing Good User Stories”

[White Paper] – 3 Planning Stages in Agile

Three Planning Stages for Agile

(c) Allan Kelly

It’s great when people write out a solid article. We like this one because it’s short and to the point:

“One of the criticisms that has been levied at Agile approach is that it foregoes planning… [Planning] occurs not once at the start of a project but continually through the life of an Agile team.”

“In Agile, near time planning is a team exercise [iteration planning]… While no plan can accurately predict the future there is still a need for plans that facilitate co-ordination between teams. This is where Release Plans and Roadmaps come into play.”

Continue reading “[White Paper] – 3 Planning Stages in Agile”

[Agile Guide] – Agile Product Management – Product Owners are Key

We like to think of Product Owners as a pivotal piece to the whole Agile process. We actually wrote about Product Owners before as a key role in Agile before, but sometimes it’s nice to see others writing about the exact same thing.

Agile cannot be successful without an engaged and available Product Owner.

Steve Swedler agrees with this point.

Continue reading “[Agile Guide] – Agile Product Management – Product Owners are Key”

[Agile Guide] – UX and Agile Development

We came upon an older post by Jeff Patton on UX and design. Some of the many questions that clients ask is, “How design fits with in Agile environment.” One of the easiest ways to start this process is have an iteration zero. While we talked about this before, it really is just the tip of the iceberg.

To fully realize the potential of fitting design into an Agile environment we must begin thinking about the broader scope of things. Good thing too, Jeff Patton already outlined 12 of the ways that designers need to fit their thinking into Agile. While often anyone who is set in their ways go through a process of anger and denial in Agile transformations, Craig Villamor tells us that essentially, they need to get over it and get with the program.

“But, there’s an important point here: if you’re a user experience professional, you will need to adapt your current practice to work within an Agile value system and lifecycle. The sooner you get through the first four phases and begin that adaptation, the better.” – Jeff Patton

So what are the 12 steps distilled?

Continue reading “[Agile Guide] – UX and Agile Development”

[InfoGraphic] – What is a Product Owner Responsible For?

Sometimes pictures are the best way to communicate something. When we came across this diagram of a Product Owners responsibilities, we liked it a lot.
Here’s a list form.
Product Owner Responsibilities:
  • Creates the product vision
  • Grooms the product backlog
  • Plans the release
  • Collaborates with ScrumMaster and team
  • Manages the product roadmap
  • Attends the sprint meetings
  • Collaborates with stakeholders
Product Owner Artifacts:
  • Product vision
  • Product backlog
  • Release burndown
  • Product roadmap

Agile Estimating 2.0 – A Cheat Sheet

Agile Estimating 2.0 Cheat Sheet

Steve Bockman has supplied a pretty cool cheat sheet for doing an Agile Estimation exercise. This exercise reminds us of the Agile Estimation practices from Manoj Vadakkan at PW&WCBA (here).

Take the exercise for a spin and see if it can help your team estimate your stories better and more accurately!

[HT: SteveBockman]

[Agile Guide] – PechaKuchas – How a Team Can Self-Educate Continually

[First: See my Agile 2011 Presentation on Pecha-Kucha HERE]

Never heard of PechaKuchas? Well neither did we until we had a client with some developers who were doing it. So what is it, exactly?

A PechaKucha is:

  • 20 slides (pictures), 20 seconds each.
  • Started in Japan in 2003 when designers wanted to show their stuff to the public.
  • It means “Chit Chat” in Japanese.
  • It creates discussion and collaboration.

Meaning, that a presenter goes (very quickly) through a powerpoint slide deck of 20 total slides talking about each slide for 20 seconds. This is a total of 5 whole minutes! Then discuss.

Ok. So where’s the value?

Continue reading “[Agile Guide] – PechaKuchas – How a Team Can Self-Educate Continually”

What’s Being Reported in Scrums – ScrumMaster Role! (Part 2/2)

Scrums, as we’ve talked about before are an integral part of Agile software development. Frankly, even if you’re not Agile, you can participate in Scrums. I suggested a little while back to a friend and CEO of a company that he start doing scrums for his development team even if they aren’t really doing anything Agile. Reason? To begin the process of disclosure and transparency to the company about what is going on so communication and collaboration can permeate the business. So far, he reports that it’s been a great step in their business!

So let’s review the purpose of the ScrumMaster:

Continue reading “What’s Being Reported in Scrums – ScrumMaster Role! (Part 2/2)”

What’s Being Reported in Scrums? – Give Me More Information! (Part 1/2)

Scrums can be a great opportunity for the team to disclose to others what is happening, recently, today, and what needs followup or help on. Scrums are a great way to communicate daily.

Besides scrums, many managers and even employees have a lot of reports to give, status reports and the like. The real question is, are we giving enough information in our update status reports or giving enough information to take action from during our scrums?

Continue reading “What’s Being Reported in Scrums? – Give Me More Information! (Part 1/2)”

Agile Guide – Conversations Around Definition of “Done”

Defining what “Done” means for an IT group can be as hard as herding cats together. Frankly, in my experience, it’s always been a struggle to get a team to discuss openly and honestly about what “Done” means. I’ve been finding that it is necessary to have a designated time to really sit down with the team and discuss what “Done” means, and not have one-off conversations, for example, at the end of a retrospective meeting to figure out what “Done” means for the team.

Well, enter Rachel Davies with a fantastic (and well documented) way to have your team discuss what “Done” means and how you can follow her way of facilitating these types of meetings and conversations.

Continue reading “Agile Guide – Conversations Around Definition of “Done””

Agile Guide – Building A Kanban Board + Discussion

We here at Agile Scout love How-To’s and Guides on anything that can help out the greater community.

We recently came across a blog entry by Cuan Mulligan that depicts his notes from a Skills Matter session with John Stevenson.

Talk about a great outline!

Cuan takes us through not only the 8 steps to creating your Kanban board, but also some discussion points around estimation, standups, how to handle bugs and defects, as well as team leadership.

Continue reading “Agile Guide – Building A Kanban Board + Discussion”

Scrum of Scrums – Valuable Time Spent

Scrum it up!

Multiple teams, cross-team issues, dependencies, multiple-stakeholders, and multiple project timelines! Sounds complicated! Yes, it can be.

I’ve found that many times a scrum of scrums meeting can be a very valuable part of disseminating information across the enterprise as well as getting project leaders and product owners on the same page, especially if it’s a many-to-one relationship (multiple product owners and one development team).

For those who don’t know, a Scrum of Scrums is a scrum team made up of representatives from each of several other teams (usually the product owner). Just like a regular scrum team, the Scrum of Scrums works iteratively to deliver value in the form of removed organizational obstacles. Scrum of Scrum meetings usually are right after a regular scrum meetings in the morning. If we have a scrum meeting for development at 9:00 AM, then the scrum of scrums is at 9:15ish.

Continue reading “Scrum of Scrums – Valuable Time Spent”

Product Owners are KEY!

We’ve talked about before how important product owners are in the whole agile process. This is still true. This will always be true!

These product owners are Very Important People as the PO is the person responsible for determining what the team is going to build. This is an important construct in Scrum because it unifies the voice of the business for the team. They are also the ones that set the priorities for the team as well. When there are changes in requirements, the PO continuously makes the decisions and gives the latest information to the team about the changing priorities. Development teams are always asking the questions: “What do you want me to build? What is the business priority?” – The PO tells us!

Continue reading “Product Owners are KEY!”