The Pre-Tax 401(k) and Free Money

Without a doubt, the most overlooked employment perk is the pre-tax 401(k) plan. It is an incredible benefit and it is like having thousands of dollars of free money! For some reason, IT Consultants often fail to take advantage of 401(k) plans provided by their firms. According to industry sources, the IT Consultant participation rate in 401(k) plans is only 10 percent (10%). Given the transient nature of consulting, that probably should not be surprising. But while it is true that many positions are short-term (lasting from a few months to a year), others extend considerably longer – often for multiple years. Even for shorter duration assignments, the savings you gain can be well worth the effort of completing some basic paperwork.

The fundamentals of a 401(k) is are pretty easy. You can take up to $17,500 of your annual income and contribute it directly to your 401(k) directly from your paycheck. And if you are 50 or older, you can contribute up to $23,000 in “catch-up” contributions! Surprisingly, according to CBS News, only 5% of 401(k) participants max out their contributions. Keep in mind that some firms will make you wait 90 days or more before you can start contributing; others, like MATRIX, permit you to start contributing almost immediately.  401KThe money is taken out of your pre-tax income, which means you do not pay federal or state tax on the deducted amount. The money is, however, according to the IRS, “subject to withholding for Social Security and Medicare taxes.” After the money is deducted, you can then invest as you see fit, based on the options provided by your employer’s plan. Hopefully, with the benefit of compounding and regular growth (both tax free), it turns into a small fortune by the time you retire. Then you pay taxes on the money when you withdraw it.

There is another benefit about putting money into a 401(k): you won’t spend it! This sounds obvious, but I have found that in my younger days, the more liquid money I had, the more tempted I might have been to spend it on things I did not really need (i.e. flashier cars, computers, hi-fi stuff, etc.). By the way, in most cases, if you leave a company, you can move your 401(k) to your new company’s 401(k) or IRA without a penalty.

So what is the downside? Well, you do pay the taxes when withdrawing any or all of the money after the age of 59.5. And if you need the money at any point before that, then you will pay hefty penalties of 10% plus your marginal tax rate for what the IRS terms “early withdrawal.” The potential also exists for tax rates to be higher when you retire than they are today. Since all of your contributions would be taxed at that future (higher) rate, you could end up paying more in taxes on the 401(k) dollars.

With that in mind, you must be thinking, “okay, so tell me how the ‘free money’ works.” Here is how: let’s say you contribute 20,000 per year. And you make more than $85,650. Therefore you are in the 28% tax bracket for federal taxes and 6% tax bracket for Georgia, ergo 34% taxes total. I am going to oversimplify a bit and skip all of the exemptions, etc., that you might qualify for. You elect to contribute $20,000. You save $20,000 * .34 = $6,800 in taxes! You can take a family of four to France for a week on that kind of money. Looking at it another way, under normal circumstances, if you took $20,000 - $6,800 = $13,200 in your pretax income, it would have to grow more than 50% to get to $20,000. Thus contributing $20,000 in pre-tax income is like getting 50% growth immediately. And that is some pretty good free money.

I will try to cover the benefits of compounding soon, because I think that is something else that a lot of IT folks tend to be unaware of. Until then, keep at it!

Special thanks to Susanne Baskin.

About the Author: 

Narayan Sengupta has been building databases for almost 20 years.  He enjoys spending his spare time with his daughters, traveling, and making presentations about American World War I and World War II history. He can be reached at

Posted in: 
Job Seeker

Benefits Reconsidered: Why Your Employer’s Plan May Be Worth the “Hassle”

It’s never been a better time to consider being a career consultant. Back in “the day,” being a consultant often meant securing your own benefits (your own contract opportunities, and your own payroll/taxes). Thankfully, professional staffing companies (like MATRIX!) have come to the rescue, and many are now providing benefits to their consultants. In 2014, most companies will be required to offer healthcare to their full-time employees (or pay a penalty). Also in 2014, healthcare reform’s “individual mandate” begins. This mandate requires most individuals (you!) to have a minimum level of healthcare coverage, and failing to do so will result in paying a tax.

It’s not uncommon for consultants to find convenience in securing an independent healthcare policy, outside of their employer. I call this the “hassle factor.” Who wants to change healthcare policies each time a short-term contract ends? Just reviewing the plan summaries can be an exhausting experience, not to mention the possibility of changing doctors or prescriptions. Well, as convenient as it may be to keep an independent (non-employer) policy, let me be the first to tell you that you may be leaving good money on the table.

Here are a few reasons to strongly consider your employer’s benefit offerings:

  1. Health InsuranceYour cost is pre-tax! That feature alone can save you thousands of dollars per year. 
  2. Many employers subsidize their coverage (MATRIX subsidizes up to 67%!)
  3. Employer plans are designed by benefits professionals, whose aim is to offer and design the best coverage for the price on their employees’ behalf.
  4. Being a participant in a large employer group spreads the risk and minimizes your exposure from a large claim.
  5. You can extend your group healthcare up to 18 months in most cases after your job/contract ends through COBRA.

Healthcare reform may drive this employer advantage further by mandating that the employer not charge more than a percentage of employee income for their healthcare coverage. This may lead to greater employer subsidies, which may mean less cost for you over time.

So, next time you start a contract, change employers, or face your employer’s annual Open Enrollment, have an open mind and consider their benefit offerings. Doing so may provide you and your family with more comprehensive coverage, better pricing, or both. I would say that possibility is worth the “hassle.”

About the Author: 

Susanne Baskin is the Benefits Manager for MATRIX Resources. She has 15+ years of experience in Human Resources and Benefits Management in the financial, banking and staffing industries. For more information on the subject, you can contact Susanne and the HR department at

Posted in: 
Job Seeker

The Big Data Explosion: Ingredients of a Great Data Scientist

The Big Data explosion has brought significant changes to the way many companies think and act about their data. Historically, due to technology limitations and cost, significant amounts of data generated by organizations went underutilized and mostly discarded or archived, the latter generally being just the step prior to discarding it. Fortunately, with the appearance of open source and affordable data intensive computing, such as the LexisNexis HPCC Systems platform and Hadoop, the value of this data has been rediscovered, and advances in related fields such as Statistics, Machine Learning and Natural Language processing have even made some of this data invaluable.

However, no technology and/or data in the world can be leveraged without the proper associated talent, and a number of specific skillsets started to be required as part of the not very well defined “Data Scientist” job. But what is a Data Scientist? And what skills is this role supposed to have that make it so invaluable in the Big Data wave?

As well versed readers may have noticed, there are no (or very few at most) academic institutions offering a Data Scientist degree. And by reading job posts, it seems there is no complete consensus on what the skillset should be, but I’ll try to list the most important traits of a Data Scientist based on our experience at LexisNexis.

First of all, one of the most fundamental skills is knowledge of data analytics; after all, a Data Scientist will be dealing with data all day long, and solid understanding of the different methodologies used to discover insights in the data is critical for the job. But as you may have already realized, most of these methodologies are based on mathematics, probabilities and statistics, so a deep understanding of calculus and linear algebra are integral (no pun intended) to the task. Possibly required additional knowledge is related to the so called Natural Language Processing, which adds understanding of grammars and parts of speech to the statistical foundations of term frequencies, co-occurrences and co-locations. And since knowledge of the data is not something that can be achieved in a vacuum, as the value of a particular dataset is highly dependent on the type of business, a good understanding of the different aspects of the business premises and its value proposition are very important to provide adequate context to the Data Scientist.

So far, we have three pillars of a Data Scientist: data analytics, mathematics and business knowledge. It is probably hard enough in itself to find candidates that can cover these three required traits very well. But this is not all. Unfortunately, a fourth key ability to succeed is being able to develop and implement, even if just as part of the routine experimentation, algorithms to mine the data at hand. And this one ability requires computer programming and algorithms knowledge (from the Computer Science career). It is not enough knowing which particular optimization method should be applied to a particular convex function, it is important to know how to implement and code it too!

So, when you are planning to hire your next Data Scientist, think about the skills you will be asking for. What you will really be looking for is a person who has a good mathematical foundation, understands data and data related methodologies, can comprehend the business goals, and can develop computer programs to implement theoretical concepts for a data analysis practical application.

And you thought that looking for a Rocket Scientist was hard!

About the Author: 

Dr. Flavio Villanustre is the Vice President of Technology Architecture and Product for LexisNexis and leads HPCC Systems. In this position, Flavio is responsible for Information and Physical Security, overall infrastructure strategy and new product development. Prior to 2001, Dr. Villanustre served in different companies in a variety of roles in infrastructure, information security and information technology. In addition, Dr. Villanustre has been involved with the open source community for over 15 years through multiple initiatives. Some of these include founding the first Linux User Group in Buenos Aires (BALUG) in 1994, releasing several pieces of software under different open source licenses, and evangelizing open source to different audiences through conferences, training and education. Prior to his technology career, Dr. Villanustre was a neurosurgeon. Dr. Villanustre and the HPCC Systems team can be reached at or @HPCCSystems

Posted in: 
Hiring Manager

The Agile Project Manager—Driving Value or Where’s the Beef?

There was a wonderful commercial I remember from years ago where a matronly woman named Clara Peller judged hamburgers by the amount of beef she found in them. Quite often, when she was disappointed in her quest, she would shout “Where’s the Beef?” in frustration. Wendy’s was the chain who came up with the advertising idea and to this day the line has become a catch-phrase for value delivery and customer expectations.

Where's the Beef - Image 1I guess Clara was onto something though. In my experience, business’ often miss the beef when they’re trying to deliver value to their customers—particularly in the software product arena. I don’t know why that is exactly. Sometimes I think the developers are too abstracted from their customers. They can rarely touch or observe them. Or understand their true challenges. So they’re guessing when it comes to needs—sort of throwing the software “over the wall” for feedback.

Quite often they are under the gun to deliver a smorgasbord of features. Almost as if no one knows what the customer needs, so they shotgun scatter individual features hoping to ultimately hit the customer’s needs. Fingers crossed. While this may be somewhat successful, it also results in delivering low value features that dilute the focus of the team and increase product development costs. From my perspective,  nothing could be more wasteful.

Wouldn’t it be wonderful if we could focus entirely on “The Beef” in application development? Spending most of our energy focused on delivering high-value and high-need solutions to our customers. Cutting through the clutter of disappointment and ambiguity and simply working on what matters most?

While it sounds like a fairy tale, the agile methods aspire to just this purpose. But it’s not easy to achieve and the effective Agile Project Manager plays a wonderful role in this quest. In this post, I want to share some ideas on how to focus the team towards just such value delivery. Fingers crossed…

A Prioritized Backlog!

One of the first mechanisms that drive value is the Product Backlog—the simple prioritized list that drives what agile teams build. Every team should be laser focused on prioritizing their backlogs in 1..n order. There can’t be three or four priority one features—there can be only one; then two, three, and so on.

Trust me; your customers and stakeholders will want to play infinite games with priority. I’ve seen cases where they have groupings in a spreadsheet that are prioritized and then sub-features broken out within each of them. They’ll insist that they can’t decompose the value out any further as they try to overload priority. This (1a, 1b,..1z) approach allows them to escape true prioritization and selection, also indicating their innate inability to make hard choices regarding what’s truly most important. Don’t let them do that!

An effective product backlog is always in linear and priority order. The team will always deliver the highest priority features first. They will work on them first, finish them first, ensuring the customer is engaged as appropriate in their development. They’ll also acquire customer sign-off for acceptance of each story before they move onto others.

And since the customer is the final arbiter of priority, they shouldn’t really complain about this approach. It’s just that we’ve historically allowed them to give us large lists of features without making finely grained priority distinctions—so they’ve gotten a bit lazy.

When encouraged (forced) to prioritize, I’ve never seen a stakeholder who couldn’t do it.

Customer-Driven Value

Where's the Beef - Image 2Prioritization can also be driven by perceived value—change that to should be driven. One technique used by many agile teams is the notion of Value Poker. It’s a variation of the popular Planning Poker technique that is used for User Story size estimation. But instead of determining size of stories in story points, we use value points as the determinant.

In this case you use a deck of cards labeled from 1-10, one being the lowest value and ten the highest. For each user story or theme/collection of stories you ask a group of various customers and stakeholders to ‘vote’ on their view to value of the story. You take a round-robin approach discussing the ‘why’ behind the highest and lowest values—letting the team express their views towards value nuance.

Once the discussion is over, you re-vote and re-discuss until you narrow the value as much as possible. Sometimes you gain agreement across the team. Sometimes you simply get a range.

You might even compartmentalize values from the different perspectives of the team. For example, the quality and testing folks’ might value a particular story as a five, while the business folks’ value it as a three and development or technology folks’ as a one. All of their valuations provide important data as to how you cross-functionally value the feature.  And clearly this spread would generate some meaningful discussion across team members.

This logic might be applied to multiple stakeholders as well. For example, the North American stakeholders might value a feature at six, while the EMEA stakeholders think it only a three. In all of these cases, discussing VALUE as a distinct attribute helps the team in prioritizing and in deciding how much fit & finish to apply to individual features.

A Variation

Where's the Beef - Image 3A truly effective variation on the Value Poker technique is to give every voting or contributing partner a ‘pool’ of funding to spend as part of their voting. So not only are they voting on a value, but they have to invest a portion of a fixed pool of dollars on the feature as well.

Quite often monopoly money or a similarly fun equivalent is used for this purpose.  Let’s say everyone gets $5,000 to spend on their features as we play priority poker. In one particular case, a business stakeholder votes a nine for a feature.

In order to emphasize the importance, they put up $1,500 on the feature or about 30% of their available funds. In fact, they only spend their pool against a total of seven features. While they continue to prioritize subsequent features, they’ve clearly communicated their views towards value. In fact, that $1,500 feature ends up being the #1 priority with a total value pool of $12,000 across the entire voting team OR 25% of the total available pool.

So here’s an interesting question. If you’re implementing this feature, what does #1 Priority convey vs. #1 Priority AND 25% of the value pool? From my perspective, there’s a large difference. This feature is a much more significant portion of the value and requires particular care in execution. I hope you see the difference.

Minimal Marketable Feature (MMF)

Often in agile teams, singular stories don’t have sufficient mass or impact to effectively be valuated by the team or customer. Earlier I spoke in terms of themes of stories. This is a common way of bundling stories together that have value and meaning as a collection. Not only does it help in developing sets of meaningful functionality, but if you prioritize at the thematic or collection level, it simplifies your prioritization. It also has more meaning from the customers’ perspective.

A variation on this theme (pun intended) is the Minimal Marketable Feature or MMF. This concept originated in the Kanban and Lean spaces. Essentially, it’s the same as a theme, but it brings to bear the notion of deliverability, marketability, and overall customer usage.

Quite often an MMF is larger than a theme. It could be equivalent to a user story epic and require several sprints to complete. However, once complete, the team will usually physically deliver the MMF to the customer—for example, pushing it into the production environment.

MMF Driving Synchronization & Clarity

Lately I’ve been coaching teams that are struggling with their focus. There’s an anti-pattern that affects many teams where they start sprinting before they understand the business case and intent for their release(s). They’re delivering stories, but they don’t necessarily understand what the minimal set of functionality that their customers are looking for.

Not having this clearly understood becomes an impediment for them. Quite often their customers have an expectation of delivery that is quite different from what the team is delivering.

One nice way to connect the two back together is to establish a view towards the releases’ MMF. Part of defining the MMF is the round-trip discussions that occur as the teams’ estimates / sizes the stories within the MMF and the customer reevaluates whether they truly need that functionality given the investment of time.

This collaboration dove-tails quite nicely into release planning—as the team narrows into fitting the MMF into a specific release window.

I’ve even seen multiple sorts of MMF’s be developed for release planning—for example, a UX MMF that tries to capture usability and interaction flows vs. the cost of implementing them. Or similarly, an Architecture / Refactoring MMF that tries to guide these sorts of trade-offs.

I consider an MMF to be a necessary component of agile project chartering and release planning and develop them as part of any significantly sized or scoped projects.

Tracking Value

One of the wonderful additions to your tool-set as an Agile Project Manager is burning down (or up) the value of stories, themes, or MMFs. You’ll want to setup a burndown chart in a well visited location that burns down team delivered value. As with all burndown charts you’ll want to keep everyone’s eyes on progress and interacting with the team over progress and flow.

You’ll want to calculate total value for a release or project. Then setup your burndown on an iteration-by-iteration basis.

If you’re getting healthy agile behavior within your team, you’ll see value being delivered in a front-loaded fashion. You should also see healthy done-ness and quality attributes as these high-value features are delivered. In fact, I usually expect teams to factor in value as part of their overall quality and testing strategies.

Wrapping Up

Agile Project Managers don’t just care about by-rote execution of tasks or stories. No! Instead they focus their teams on a multi-faceted and nuanced view towards customer, value-driven execution.

Not only are they hoping to deliver value first, but they’re also hoping that by doing so, the customer may achieve a “good enough” view towards incrementally delivered product increments which allows the team to stop the project earlier than planned.

Stopping after delivering the features and functionality that truly matters the most to them. Sort of gaining their value and then moving onto their next highest value-driven project. It’s this sort of value-trimming that can truly make an agile team stand-out from their traditional counterparts and move so much faster. That is if stakeholders step out of their comfort zone and truly focus on value first.

About the Author: 

Bob Galen is the Director, Agile Practices at iContact and founder of RGCG, LLC a technical consulting company focused towards increasing agility and pragmatism within software projects and teams. He has over 25 years of experience as a software developer, tester, project manager and leader. Bob regularly consults, writes and is a popular speaker on a wide variety of software topics. He is also the author of the book Scrum Product Ownership – Balancing Value from the Inside Out. He can be reached at

Posted in: 

The Agile Project Manager—Viola: The Great Reveal

I remember the day as if it was yesterday. It was my first sprint review at a company I’d just joined as an agile coach. They’d been ‘doing’ Scrum for several years and I had gotten the general sense that they were well disciplined and mature agilists.

The Great Reveal - Image 1So when they scheduled a series of sprint reviews to expose the x-team efforts of their latest sprint cycle, I was understandably excited. So I got into the room early to get a good seat and was eager with anticipation.

Gradually, the room filled and it became quite noisy, which only drove my anticipation higher. Then the first team took “the stage” and began their review. They popped up some PowerPoint slides and away they went…

Their deck was polished. They had lists of things they’d done and down-loaded pictures and jokes for lightening the mood at appropriate points. They marched through the work that they’d done…one slide at a time and at appropriate points the audience politely applauded their approval.

But it struck me mid-way through the first review that something was missing—something really, really important. There was no working software.  How could this be I thought. The whole point of the sprint review was to expose working code to stakeholders for review & feedback. Then I thought—this was probably an exception or special case—specific to just this team.  Surely there’s working software coming up next.

But, one-by-one, each subsequent team followed the same pattern—showing humorous slides and textual representations of effort, but no working code to be seen. Slowly and then more quickly my enthusiasm waned and I became quite frustrated. Not so much with the team, but with whoever had explained the purpose of a sprint review to everyone. Clearly…they didn’t “get it”. And neither did the stakeholders, as they continued to politely chuckle at the jokes and applaud each teams’ efforts. It seemed as if the ceremony was simply there to check a box in the Scrum process list.

Never Again!

The Great Reveal - Image 2Needless to say, the teams never took quite this same approach again in their sprint reviews J. While I truly honor the notion of self-directed teams, I immediately laid out some guidelines and goals for our future sprint reviews.

Some of them aligned quite naturally with the Agile Manifesto, for example the notion of demonstrating working code at the end of each iteration or sprint. But some of the guidelines were unique to our organizational and cultural dynamics.

That’s actually the focus of this post…I want to share some of the guidelines, strategies, and the mindset we leveraged to turn-around our sprint reviews. Over time we move from:

  • Polite applause enthusiastic cheers and aha moments
  • Polite applause gaining congruent & constructive feedback
  • Selling & marketing our results making them transparently honest
  • Small crowds stand room only & video taping
  • PowerPoints working software whenever possible
  • Entertainment showing business value & exposing team effort
  • Going through the motions intentional and congruent feedback
  • Selling and marketing our results having them speak for themselves!

Surely it didn’t happen overnight and we continued to adjust and fine-tune our sprint reviews over time. However, we achieved a state in our reviews where they became the cornerstone for our agile adoption across the organization.

Let me share some of the things we focused towards…

Guidance towards “Excellent” Sprint Reviews

In general, I like to consider the sprint review as a “big deal”. Why? Because it is.

An agile team has spent a focused period of time, working on the most important stories on the planet, and is ready to deliver working software surrounding those features or stories. This stuff is hot off the presses and people should inherently care. They should be excited to see the results. Heck, you should have to beat them away at the doors.

It’s the teams responsibility to effectively REVEAL their efforts. And I’m not simply talking about the software. No, they should be telling & showing a story surrounding their work. It should contain context and narrative. There should be a connection to the last sprint and towards future sprints.

So below I want to share some critical focus points and a sample review agenda for your consideration. I hope the specific ideas help you to improve your reviews, more effectively engage your stakeholders, and create a more energetic reveal for your teams.

The Great Reveal - Image 37 Key Focus Points for your Sprint Reviews

1)  Ownership  - We established that the Product Owner ‘owns’ the overall pattern for the Sprint Review. Sure, it’s a “whole team” thing. But at the end of the day, external communication, showing planned-delivered value, and gathering & adjusting to feedback are primary aspects of the PO role.  They’re also responsible for getting people in the review—so if attendance is spotty, they’ve got work to do to figure out why and to change your patterns to get the “right people” in the room.

Very often I think of their role as one of Master of Ceremony—where they are conducting all aspects of the review. Certainly not doing everything themselves, but guiding the overall quality, focus, and results of the review.

2)  Format  - We put a lot of thought into the scheduling & timing for the review (or reviews if you’re part of a multi-team initiative). You’ll want to get into a regular tempo (day & time) for your reviews. Within the context of the review, you’ll want each team to follow a consistent flow (see potential review agenda below).

In our case, we had multiple teams demoing on the same day—as our sprints were synchronized. So, our format was really a cross-team agenda that sliced a 3-hour time slot into appropriate stages for each team. Not only did we plan each review, but our Chief Product Owner took a stab at conducting overall flow across the teams. 

3) Sprint Goals  - I personally like the view where the review is “hinged” on the sprint goal(s) that the team(s) signed up for. Quite often I tell teams when they’re crafting their goals to think about the e-mail invitation they’ll be sending out for the reviews. The ‘story’ of the sprint then is tied to the goal and how the team reacted towards meeting the goal.

And you should be honest about how the team delivered to their sprint commitments, so “Call It” as a success or failure. But never, ever let the term ‘failure’ be used to browbeat the team. Failure is a part of teams learning and the organization needs to adopt a “Fail Forward” attitude. 

4) Whole Team View  - As I said, I like the view where the Product Owner is the Master of Ceremonies, the Scrum Master is the facilitator (if needed) and the entire team gets a chance to “show off” their results in each review. This whole-team approach serves to give your team transparency and the chance to shine—so round-robin your demo individuals and give everyone (person, role, etc.) a chance to show off their work and results.

And no, don’t ‘force’ introverts to speak uncomfortably in a large forum. Make it encouraged and optional. Very often these folks can serve as the ‘driver’ for the demo—so quietly participate. But do engage the whole team!

5) Preparation  - If there’s a key to a solid sprint review its preparation—somewhere safely between “way too much” and “totally winging it”. You should put some thought into what work is relevant for the review, in what flow should it be demonstrated, and how it connects to previous and upcoming sprint work.

Quite often someone with a QA background will develop a review ‘script’ that helps the team expose their efforts in a cohesive way. Ultimately, the Product Owner should have the strongest voice into what gets exposed and why—setting the stage for the ‘reveal’ with the stakeholders.

If in doubt, reserve sufficient time in sprint planning for review preparation and DO prepare.

6) Execution & Demonstration  - The review demo needs to be smooth, thoughtful, polished, and ultimately—the software needs to flawlessly work. Dry-running the demo and having everything pre-setup is a must. You should also do timings to ensure your demos fit into your allotted time. And don’t forget about Q&A time.

Beyond the demo, you need to tell a story that encompasses your feature workflows. I’ve seen teams in their first sprint show an architectural diagram that reflected the work they planned for the upcoming six sprints. Then in each sprint review, they “filled in the boxes” as they began fleshing out the application architecture. I thought this approach was an outstanding way to “connect the dots” for the audience.

From my perspective, ALL WORK that a team took on in a sprint is a candidate for exposure. That might include: features, enhancements, bug fixes, refactoring, documentation, testing infrastructure, virtually everything. Sure, some things might require some finesse to demonstrate or illustrate, but if its work the team did—it’s a candidate for the review.

And finally, be ready to explain things sufficiently so your audience UNDERSTANDS what you’ve just shown, its significance, and the level of effort behind it.

7) Wrap-up  - Finally, we always wrapped up reviews with a general request for feedback—both on the software itself, but also on our review dynamics. Were the transitions well made? Did we explain what we did? Do you know how to send us your feedback? And what can we change to make the next review even better?  We usually only spend a few minutes here, but it’s time well spent. If you’re familiar with the notion of a Fist-of-Five, we usually leveraged that technique for closing feedback.

Sample meeting agenda

Consider the following as a healthy template for your teams sprint review agenda—


Team Chart

  • Who’s-who: names, roles, and location of team members
  • external folks who helped with the sprint

Acknowledgements – Appreciations

  • certainly shout-outs for team members
  • but also a good time to recognize “external folks” who were instrumental in the sprint

Sprint Goal

  • articulate the Sprint Goal, speak to any adjustments that were made during the sprint
  • call it: was the sprint a success, i.e., did the team meet their commitment to the sprint goal?

Strategy? Success? Efforts? Discoveries? Results?

  • share any relevant strategies the team used to deliver the work
  • explore the effort behind the sprint
  • were there any discoveries that were unexpected; any critical results
  • all of this is to give the audience a “behind-the-scenes” look at the teams sprint

Demo’s; Q&A

  • demo the selected set of user stories / features – allow for Q&A

Coming Attractions

  • speak to progress to release goal(s) and upcoming work in future sprints

Fist-of-Five Towards Improvement

  • engage the audience in review performance feedback


Wrapping up

I simply can’t tell you how good it feels to have a high-impact sprint review. And while I put a lot of pressure on the Product Owner and team for the results of the review, as an Agile Project Manager you play a central role as well.

Teams often get “caught up” in the work of the sprint and short-shrift the review preparation. In fact, this is a common anti-pattern. You can turn this around in sprint planning—asking the team to plan for and allocate sufficient time towards the review, while also reminding them as the end of the sprint approaches to consolidate their work.

Remember, the review is also a “QA checkpoint” for the team. There’s nothing like pulling things together and demoing them—to bring a healthy dose of reality to a teams’ sprint efforts. You always shake things out—environments that don’t work, integrations that weren’t made, and interactions that were forgotten.

So Agile Project Managers, I hope this post has inspired you to take charge of your reviews and make them the most powerful event within your agile teams. While it is certainly the teams’ responsibility to prepare and deliver, you can influence the attitude and approaches. You can also amplify the positive feedback you’ll get as you improve.

About the Author: 

Bob Galen is the Director, Agile Practices at iContact and founder of RGCG, LLC a technical consulting company focused towards increasing agility and pragmatism within software projects and teams. He has over 25 years of experience as a software developer, tester, project manager and leader. Bob regularly consults, writes and is a popular speaker on a wide variety of software topics. He is also the author of the book Scrum Product Ownership – Balancing Value from the Inside Out. He can be reached at

Posted in: