ODDI’s Gone Agile!


Hey there, my name is Son Tran and I’m the Agile Project Coordinator at ODDI!

Agile? What’s that?

Many people use the word liberally, but what does it really mean to practice agile? Agile doesn’t mean working faster. It doesn’t mean being highly adaptable to the winds of change.

agile definition

And when I hear people say agile doesn’t involve any planning, I’m just like:


Agile project management is a team-based approach where the interactions among team members take precedence over processes and tools. The team commits to creating functional, viable products by completing a defined list of work within a time-boxed iteration known as the sprint.

Sprints can run between two to four weeks. At ODDI, we opted for the two-week sprint. Collaborative work is the core practice. It brings together the decision-making, skill sets and experience of the entire team to achieve a sprint’s goals. The end result does not have to be production-ready. As long as your team commits to taking an iterative approach toward improvement, you’re on the Agile path. This may take two or three more sprints–and that’s just fine.

Take it from Neil deGrasse Tyson:

iterative approach

Moving Toward Agile at ODDI

Four months ago, I joined ODDI as its new Scrum Master. While the position’s title comes from this game:


In reality, I serve as the enthusiastic cheerleader for the Agile process, cheering on my team members’ commitment to achieving the sprint’s goals that’s more akin to this:



When I arrived, an online agile project management tool was already up and running. It even had a few projects with a backlog of user stories.

What’s a user story, you ask? A user story captures, in everyday or business language, the functions a business system must provide and is the basis for requirements-gathering in the Agile process. It embodies the ‘who,’ ‘what’ and ‘why’ of the requirement in simple terms and is primarily written by the Product Owner of the agile project team. In certain workplaces, they even hand write them on note cards.

User stories tend to be written in the following format: “As a user, I want to do [X] so that I can [Y].”  Here’s an example of a user story from ODDI’s Analytics project:

“As a content editor, I want to view analytics by characteristics of content so I can compare performance by topic, byline, or type of static page.”

On my first day, there was an ample supply of user stories in the product backlogs. It was a veritable fifty-two card pick up! I enlisted my services to help two existing teams, both of which had unknown velocities–how much effort a team can handle in a sprint. For one project, the product owner had user stories ready to go into upcoming sprints.

For another, the product owner had to develop the user stories and figure out their priorities Prioritization alone was a daunting task. In fact, prioritizing the user stories was her top priority:



Sizing the Stories

We prioritized the stories, but how do they stack up to one another? Instead of hours, we chose to assign story points using a technique called Planning Poker. You may think it would look bit like this:











Or even this:


But alas, no. Planning poker is a consensus-based activity a scrum team uses to assign estimates of complexity or relative effort to each user story in the project backlog.  For our planning poker, we viewed complexity in relative terms.  It’s not considered proper agile technique but you can consider complexity as a scale of the amount of time it would take a team member to complete a story (a couple of hours, half a day, a few days, a week, more than a week, two weeks).  A better perspective is to consider the resources needed to achieve the story, i.e. would you assign the story to an intern, a jr. programmer, a sr. developer or a sr. architect?

We used story point values based on the exponential Fibonacci sequence.  Using this sequence has origins in the software development world where the estimation of effort has an inherent level of uncertainty due to the many unknowns.  The Fibonacci sequence represents a set of numbers that we can intuitively distinguish by their different magnitudes.

Instead of 21, we used 20.  We chose 20 to represent the maximum amount of effort by a team member to complete a single user story in one sprint.

The structure of the planning poker goes as follows:

  • The Scrum Master presents one User Story at a time to the Team.
  • The Product Owner answers questions the Team may have about a story.  (Usually product owners do not cast cards, but our teams were so small in size that they participated.)
  • Each Team member selects a card representing his/her estimate of the ‘size’ of the story.  When all Team members are ready, all cards are presented at once.
  • If there is consensus, the Scrum Master records the size and the Team moves to the next story.
  • If the estimates differ, the high/low estimators defend their estimates.
  • The Team briefly debates the arguments and a new round of estimation is made.
  • The Team continues this process until consensus is reached. If no consensus is reached, the higher estimate is selected and recorded by the Scrum Master.
  • These steps are repeated until all the User Stories have been estimated.

If you have a large backlog like we did, planning poker can last a couple of hours. Impressively my teams had the perseverance to carry on in the same meeting with the sprint planning.

When you’re starting off in agile, there is no established velocity to estimate how much work your team can complete in a sprint. I had to estimate from my previous experience working with agile teams that a single team member could complete 10-13 story points in a single sprint. Once we determined team availability for the next two weeks, team members volunteered to take on user story assignments.

The planning process involved a lot of team involvement. It’s the agile way, after all, and it captures the trifecta of Daniel Pink’s drivers for motivation: everyone had an opportunity to steer the direction of the project (autonomy), they made a commitment to continuous improvement (mastery), and they gained a sense of how they can contribute to the project’s “big picture” (purpose).

Prioritized, story-pointed and motivated–we were ready to begin our first sprint!


Have you adopted agile project management at your workplace? Did you have similar experiences of going agile from scratch? I’d love to get your feedback!


The following two tabs change content below.
Son Tran
Son Tran is the agile scrum master at the Office of Digital Design Innovation. His interests include design thinking, innovation planning, and implementing agile practices in the federal government. Follow him on Twitter: @sont
Son Tran

Latest posts by Son Tran (see all)

Leave a Reply

Your email address will not be published. Required fields are marked *

* Copy This Password *

* Type Or Paste Password Here *