Monetizing Agile Projects

Coming from a finance background my education and experience is grounded in ensuring that money invested returns ROI.  We think of things such as ROI, IRR Cash Flow, etc…

For example when a manufacturing company decides to make a hardware purchase for machinery (any kind) to produce some type of ‘goods/product’ they perform financial analysis regarding the cost of the equipment, the rate of return that it will generate, how quickly they can amortize it and ultimately what is the net profit that the machine is expected to generate over its anticipated lifespan.

For most of my career we start on projects that have a goal in mind, potentially new revenue or cost savings, some have gone so far as to try to determine the ROI, but in general I haven’t seen the type of due diligence that manufacturing type companies perform, applied universally to software development.

This may be an underlying cause of many of the software development projects never seeing the light of day or failing to deliver the expected outcome because we never performed effective financial plans that would establish the scope and speed necessary to deliver a software product so that it warrants the investment.

In Agile I think we have ways of providing some level of financial analysis that can provide us with an understanding if an idea is worth pursuing.

1. Using the following as a guideline we can begin to estimate costs:
   1. Team Size – 5
   2. Blended Rate – $125 an hour
   3. Hourly team rate – $625
   4. Cost of Sprint(2 weeks) – $50,000
2. Let’s assume that the feature that we want the team to work on has come back with an estimate of 5 Sprints.
   1. Estimated Development Cost – $250,000
3. Let’s now assume that this investment is expected to yield an additional $1,000,000 in annual revenue.
4. Expected ROI in the first year – 300%

Before we engage our teams we need to be sure that the $250k investment will return an appropriate level of return.   In this simple example its a no brainer.

But our world of software development isn’t always so clear-cut, we often don’t know what the expected outcome will be until we release the product into the wild.  There is often additional cost for refactoring before the product hits the mark with your consumers.

But using some of these simple ways of working through anticipated costs we can easily modify the example to reflect additional Sprints for refactoring once the product is released.

In this example let’s assume that the team requires an additional 8 sprints to move from MVP to final product.

The final cost of the product would climb to $625k and our return would drop significantly to 54%.  Still not bad but not the eye-popping number we initially thought it would be.

Factor in sustainment costs into this over the life of the product and you begin to see that your investments in your software absolutely need to go through the same level of analysis as other types of large infrastructure purchases that non-software organizations go through.

I’m currently working on creating a lightweight model based upon Markowitz’s Efficient Frontier investment model that money managers use today to ensure that your risk and return threshold is aligned.  I’ll be posting my initial thoughts and approach in a coming blog.

Agile Planning and Delivery

Agile is often viewed as the way that small organizations and teams can build product quickly and in fact I believe that to be true.

Being quick and nimble allows smaller/growing organizations the ability to get into a market quickly and deliver features that larger organizations haven’t delivered yet or haven’t thought of.

This very ability to deliver new features to a market that desires them is the very reason that larger organizations need to change the way that they deliver their product.  As an organization becomes larger, the entropy that comes from that growth causes the organization to stop being a market leader and start being a market follower.

In the technological world we live in, you can go from market leader to out of business in just a few short years.  I read an article recently that suggests that Walmart is starting to show signs that its dominance in retail may be coming to an end.  I wouldn’t be surprised, as I think they have lost sight of the fact that low prices don’t always solve the things we as consumers value.  Walmart isn’t a market leader anymore, they may just not have come to that realization.

It’s this lag in reality when big companies start falling behind  Somewhere along the way almost every organization will lose its way, lose site of the very thing that caused them to be great in the first place.

When you look around in the Agile learning space you see many of the original creators of Agile and Scrum trying to figure out how to help large organizations get past their own entropy.  I don’t think that Agile can help, it can highlight where your planning and delivery processes are inefficient but it doesn’t provide the language that senior management needs to hear in order to effect real change.

If we want to help organizations transform and be ‘agile’ then we need to speak in the langauge of management, which is money.  I’ve yet to have a cogent conversation with management regarding how their lack of focus costs them money and more importantly fails to deliver the speed to market that they need in order to stay market leaders.

If you think that Agile provides you with a means to quickly change product direction in order to play defense or catchup when new features that you have been planning on are released by a competitor, then you are missing the point.  Agile does accept that change will happen, but we expect that the change will take the form of measured change in how we can make the product more valuable, not wholesale changes in direction.

Changing direction within a Sprint is something I’ve seen several times and it’s almost always driven by management.  Whether you have too many idea’s/opportunities or are just trying to stay relevant give you team time to work on one thing at a time.  Context switching reduces productivity and that you can translate into money.

The example I’ve been using recently is this:

If you managed your Sprints the way you manage your money you would go broke.  Take this example for consideration (note this is what good Agile teams should be forcing into the planning conversation).

Consider a team that has planned 20 points for the current sprint and someone (Product Owner, Sr. Management) has decided that something else is more important, like completing a feature for a key client.  The appropriate response from your Agile team is ‘Great, let the team review the request and provide an estimate’.  Right there you have probably lost 2-3 points in analysis and estimation by the team.  Once they have completed their estimation, they come back to you and tell you that it’s a 5 point effort.

You think to yourself great we can do that in this sprint,  let’s do it.  A good Agile team will tell you yes we can do it but you need to remove 2-3 points for the estimation effort AND 5 points for the new work that you want us to take on in the current sprint.  So you have LOST 7-8 points of productivity, aka value) to get 5 points of value.

If you invested 8 dollars into a business and only were able to get 5 dollars back you would quickly realize that you can’t sustain that monetarily, right?

Put this to your executives next time you have a priority conversation.  I didn’t even bring in the  technical debt we typically take on to hack something together and the lack of testing that will happen because we weren’t ready to take on the work (read no automation).

As a Finance guy I would say that this is a bad investment.  Yes I want to satisfy my customer but if they are a good customer you should be able to have an ability to manage their expectations so that the team can take on the work in the next Sprint.  Depending on when the request came in they may only have to wait 2 weeks.

Effective teams I’ve worked with use this process as a first line of defense against changing priorities within a Sprint.

Scaling Governance in Agile

Large organizations who move towards and Agile delivery model may struggle with how to scale any governance model.

I think if you polled most Agilists about governance in general, you would tend to get a shutter and an ugly stare.  Indeed we want to address technical excellence during our sprints but what we often fail to understand is that software engineers are not omniscient when it comes to all of the areas of technical acumen related to performance, security and other compliance type efforts.

As an organization grows and becomes more and more global it finds itself dealing with many different governing bodies that each have different requirements for how we deal with data protection, which in turn relates to how we develop our software.

Having run PCI compliance for a large organization I know first hand that providing specific information to developers with respect to what to look for just in a code review is an important first step.

Governance is needed for most organizations as a first defense when something happens with respect to security/privacy.  Organizations need processes in place to provide evidence to governing bodies, courts and legal inquires regarding how we protect our product our customers information.

Governance can include both standards and artifacts.  For example PCI compliance requires that we provide evidence of compliance with respect to their 13 security requirements.   From a software development standpoint these include such activities as code reviews that are focused on security, software development cycle, evidence of secure development and test practices in addition other efforts such as  Penetration testing and other monitoring capabilities.

In Agile we need to think of this in a light weight manner.  At one organization we implemented a set of standardized stories, non-functional, that were to be included into a teams feature development sprints.  For teams that are working on several sprint efforts before going into production this can work very well as the team is addressing this as part of the planning and estimation.  When the code is delivered to production the completed and accepted user stories (which have context as to what was completed) serve as the artifact for the PCI compliance (or other) auditors.

The engineers liked this because they were creating artifacts as they developed and from an organization standpoint we gained confidence in the fact that our code was being developed against high quality standards.

For Governance activities that relate to more ongoing product sustainment efforts the same standards need to apply however the manner in which we apply them within each sprint may be different that new product type efforts.  Automated testing and monitoring form a larger basis of maintaining the standard levels that we established in earlier cycles.

Recently I heard a statistic that said 90% of attacks can be mitigated by the basic block and tackle work that teams can do on a regular basis.

Governance doesn’t have to be a bad name in the Agile space, we need to view it as part of our technical excellence efforts that form the basis of high performing Agile teams.

I think Governance is an area in Agile that is ripe for development especially at scale.

BDD – Step by Step Process Tutorial

As you might tell from some of my blog topics I’m a huge believer in BDD, not just as a means to automation but more importantly as a process that helps us define requirements more accurately.

When we move into an Agile delivery model, many individuals struggle to understand how they are supposed to document everything that they used to put in their Product Requirements documents (or a whole host of other acronyms).  These documents formed the basis of our engagement with the business and with the teams that would ultimately deliver what the business thought they were asking for in the PRD.

There is an interesting game that has many flavors such as Social Telephone game, that for me, makes clear the issue with large documents that multiple groups need to review.  Each of us is individually focused on the things that we think are important and we often have different interpretations of the written word.  And as such as we work to deliver in our silos we move towards an uncommon understanding of what is being built.  I would argue that many ‘defects’ that are found are actually poorly interpreted requirements.

For those of you in highly regulated industries you know what I’m talking about.  The endless hours spent reading a single paragraph trying to derive the real intent and meaning behind the written word is exhausting and fraught with peril because if we get it wrong there are penalties and mad scrambles to implement a hack to make it work the ‘right’ way.

Software development is made hard because of these communication differences, be they cultural, language or other, they exist and they make it difficult to come to a collective understanding of what is being asked for.

User stories help break down this barrier as they define small pieces of a larger whole and place a value statement so that we understand WHY what we are being asked to build is important.  Many teams writing user stories leave off that important ‘so that’ statement.  Leaving off ‘so that’ leads to so what?

Behavior Driven Development, for me, changed the way that I looked at defining requirements because it removed the business language of things such as the business requires this, or the feature shall do that.  The statements sound powerful yet deliver little in real context for the teams to work from.

Breaking down user stories with BDD still leaves the team to work with a non-technical domain language and then provides a clear method of defining the behavior (positive and negative) for the teams to work from.

The power of context with the respective speed and quality it delivers can’t be denied.  However don’t be fooled that this is easy, it isn’t.  Agile is extremely disciplined, something many miss on their way to the Agile party.  Done right it can take your delivery processes to new heights, done wrong it becomes just another new fangled process that doesn’t work.

Below is a BDD tutorial that can get you started on your way to learning how to build contextually rich user stories.  Good luck and have fun!

BDD Training

Agile Testing

I was saddened to see that a meetup group that I managed for over two years was coming to an end because there wasn’t anyone who wanted to take on the leadership role.  When I started at a Northern Virginia startup as QA Manager I was tasked with taking on the leadership role of the DC Agile Software Testers (DCAST) meetup.

When I took over we had 25 people and when I left the group two years later  we had grown to a robust 450 and had developed a reputation as a place where QA professionals could meet to learn how they could be successful in an Agile environment.

I’ve always said that QA is the last to come around when organizations move towards Agile.  Early on in my career in Agile the QA leaders would tell me ‘yeah you guys develop however you want and when you are done, then we’ll test’.    The notion that QA couldn’t test anything until everything was done (though in reality it never was) was strong.  The feeling of power in finding defects that were typically not defects but mis-interpretations of requirements was palpable.  The force was strong with us then. (cue the light saber sound).

With DCAST I saw quickly that the people who were coming didn’t understand how they could engage in the process and more importantly they didn’t understand how they could deliver ‘quality’ without having the entire feature delivered for testing.  Iterative testing just didn’t compute.

There are many things that QA teams need to understand in order to be successful in Agile.  Some of the key elements include:

1. Automation – For QA this needs to be a key focus of development.  Automation builds what I call ‘progressive regression‘.  Instead of thinking of regression as the final end to end activity, look at it as a growing entity.  With waterfall development and more manual focused testing, you get an opportunity to perform a full regression test potentially just once at the very end of the development cycle.   This leaves little time to deal with defects that arise from your testing.  With automation and continuous integration you are effectively performing a regression test of your developed features every night.
2. Behaviour Driven Development (BDD) – The two-pronged effort to quickly develop and manage your test automation suite utilizes example based test development like BDD as your test acceptance framework.  What BDD does is ensure that the entire team is reviewing the acceptance tests that will ultimately be developed as part of the automation suite.  This process ensures highly contextual user stories that clearly define the behavior of the feature and keeps everyone focused on exactly what needs to be developed (nothing more nothing less)
3. Parallel Teamwork – With the use of BDD, QA can develop their automation code while feature development is in flight.  If the teams are working from the same story specifications then when the code is checked in the automation should be able to run with few errors.  This is a key process to develop in order for teams to deliver quickly.  By not having parallel efforts, teams will typically fall into the cadence of having automation developed in the next sprint.  Once you go down this road you will typically see automation efforts begin to fall further behind as QA will start manually testing in order to ‘stay on top of testing’.
4. Sprint Management – QA teams need to work with their team to ensure that work is being delivered throughout the entire sprint.  A common problem teams face in Agile is that we fall into the ‘mini-waterfall’ process where developers deliver the features in the last day or two of the sprint.  This leaves very little time for QA to perform ad-hoc and manual break testing along with fixing any automation breaks that have occurred once the code is checked in.
5. Zero Defect Policy – This is key.  Teams need to develop a working agreement that enforces a zero defect policy for new feature work in a Sprint.  This means that the team does not receive credit for any stories that can’t be closed out with zero defects.  This focus ensures that the entire team is focused on delivering quality.
6. Quality is EVERYONE’S responsibility – There is no such thing as ‘toss it over to QA’ in an Agile world.  Hey Developers, you have to help test if you deliver something late.   Don’t let your software engineers tell you that they don’t test.  All great developers have to be good testers ( you know TDD kind of focuses on writing tests).  The entire team is responsible for quality not just your test engineers.   Note – QA Managers this concept in no way removes the need for your existent, rather like Engineering Managers your role changes.  You should actually have time to be strategic and plan out future testing platforms and approaches for your team.

I’m glad to have led DCAST as it provided me an opportunity to help QA professionals grow their understanding of the activities and process all good Agile teams exhibit.

PMO Role in Agile – Part 2

My initial blog seemed to have some interest judging by the number of views it’s received so I’m guessing that it’s a topic that many are looking for input on.   So I thought I’d provide some more thoughts as to what a PMOmight  look like in an Agile organization.

One of the key things that changes with a traditional Project managed organization is that they must change to one that is Product managed.  What this means is that the organization changes the way that it funds its business by essentially providing Product Owners with Scrum teams that will deliver on their vision for their product.  Given this paradigm, along with the creation of the Scrum Master role, the PMO and subsequent project managers are left outside looking in.

Managing Product driven teams means that you are managing towards outcomes that delivery value over projects that deliver features.

In my previous post I provided some suggestions as to what individual Project Managers could do to make themselves more valuable and productive to their teams.

In this post I will suggest a PMO structure that focuses on the Portfolio view and leaves the operational execution of the roadmap to the Scrum Teams and Product Owner.

For this structure to work the organization needs good Scrum Masters and preferable ones that aren’t also individual contributors for their team.

The structure of the PMO will be lighter than you might think is right, but I’ll argue that if you have the same number of Scrum Masters and Project Managers you will set up role confusion that will make your entire project management process cumbersome and less productive.

The PMO structure would look something like this:

I think one of the things that a PMO organization needs to be aware of is that their focus is not on control of projects and people but on how teams are performing.

With this structure you have a thinner level of Project Managers who are focused on Program level Product Management (PPM new acryonym anyone?). Your Project Management function becomes one of oversight of Scrum Masters and working closely with Program Managers in other Product groups who probably will have cross org dependencies.  The Program Manager level in this structure is more about working to ensure that teams are working on the right things based upon the Product Roadmap and escalating when individual team priorities become out of line with the overal corporate product objectives.

What we want with a PMO is confidence and how we do that historically is to place controls, gateways and processes designed to show that teams are checking off boxes that we believe represent how a successful project should unfold (aka Project Governance)

How we do that in an Agile organization is to ensure that our teams we have a clear Product roadmap, that we are performing effective planning both in the areas of Product Discovery and Release Planning, that teams are provided time to review and estimate the work that they are being asked to commit to AND ensure that teams perform continual inspect and adapt cycles via Retrospectives.

If teams are allowed to form into solid high performing teams what you get from that is an organization that learns how to estimate accurately, which leads to consistent velocity which in turns leads to predictability….which is what we in the PMO (and Sr Management) are looking for, simple right?

What I learned years ago from my Project Management days is that Agile actually provides you with much more visibility and transparency about what is happening with your commitments,  providing you as the stewards of the product an ability to have fact based conversations with stakeholders who rarely understand the complexity of what they are asking for.

PMO Role in Agile

If you lead a PMO or are a PM and your organization is embarking on an Agile adoption you are probably thinking so how do I fit into this new paradigm and still manage the work that I’m currently managing (it won’t manage itself is what you are thinking) ?

Organizations who are now moving towards Agile as a product delivery/SDLC method will find themselves trying to figure out where their PMO and subsequent Project Managers will fit.

The problems they face are several:

Traditional Project Managers:

• Are experienced at managing to a specific plan and resolving resource issues that their specific projects are facing.  They are not typically assigned to just one project and the people they work with come and go with much frequency.  Project Managers have been for many years the ones who provide confidence that ‘someone’ has their hands on the pulse of the projects that are designed to deliver value to the organization.
• Don’t typically look at their projects as value driven, rather they are priority and resource driven.  Their focus when they are assigned to a project is about who is on my team, who can I steal from other projects and creating a plan that is often not vetted by the very people who will actually do the work and socializing that with Sr Management.
• Traditional Project Managers are excellent deflectors of blame (yep I learned quickly how to push off issues on to someone else)
• Are not typically contributing members of the team.

I don’t say these things to make Project Managers angry, I was once a PM and a very good one at that (or so I believe).  And I’m not at all implying that there isn’t a role for PM’s in Agile, but I will suggest that how you think as a PM will need to change.

For starters you need to find a way to be a contributing member of the team and not just someone who sits on the sidelines like a reporter and records what is going on to report out.

The thing that was different about me was that I always managed my teams more like a Scrum Master would.  I found ways to contribute, I gained the trust of my team, I protected them and provided guidance for individuals when they were struggling with something about the organization that didn’t make sense.  This process of engagement led me out of the PM role and ultimately into QA Management so there are growth opportunities for PM’s if you are open to learning new things.

If the team needs help in testing, learn something new and help out.

Most Agilists’ may tell you that the Scrum Master and Project Manager role are completely different.  Though they are different I would argue that project managers can fill the void of Scrum Master and gain great insight to their projects and be on point to resolve impediments more easily than be bystanders to the entire Agile process.

Here are some key areas that Project Managers should focus on during an Agile Transformation:

1. Planning – Is not a function of setting forth an unyielding plan.  Rather planning by the team is to facilitate an ever growing understanding of what the team is building.  Big Up Front Requirements convey a static nature to projects that simply doesn’t exist.  If you disagree actually track the number of times the team has to change their plans (for architecture, etc..) during a typical non-Agile project.  Teams that try to predict the future are destined to be wrong a majority of the time.  You need to become comfortable with a plan that identifies in detail only 4 weeks out.
   1. Goal – Be an active member of the team and be able to understand both the technical issues that are facing the team and bring them a clear understanding of dependencies with projects and teams that aren’t in their viewfinder.
   2. Goal – Learn different Agile planning techniques.  One of the key things that people miss in Agile adoption is that Planning needs to take place more often and that some level of upfront Discovery is not a bad thing.
2. Scrum/Agile  Activities – A Project Manager for a Scrum Team needs to:
   1. Ensure that their teams are performing effective User Story development with techniques such as BDD and Specification by Example.
   2. Ensure that their teams have a well groomed set of stories in their backlog
   3. Ensure that their teams have effective Sprint Planning and Estimation sessions
   4. Ensure that the teams utilize their Retrospectives to drive continuous improvement
      1. Goal – Become an Agile evangilist, learn everything you can about Scrum, Story writing, TDD, Continuous Integration, User Story Mappiing, BDD, Specification by Example.
3. Program Management – Is driven by the overall roadmap.  Ensuring that Scrum teams are aligning their user stories to appropriate Road Map Items keeps the organization focused on execution progress/success and provides the PMO with a clear view to all of the work that they are managing.  As an organization scales this is no small feat, so getting large sets of teams to keep up with story writing and roadmap linking is an administrative task that teams quickly tire of.  Project Managers need to provide support and assistance with the management of these types of activities in conjunction with their PO and Scrum Master.
4. Technical Knowledge – Though this isn’t as big of a problem as it was 10 years ago, many Project Managers simply don’t understand the underlying technical platform that their teams are working in.  I personally don’t think that you can be an effective project manager unless you have this knowledge.  Take the time to learn, your team will appreciate it and you will be able to have better fact based conversations with your Stakeholders regarding issues that delay delivery of projects.

BDD – Breaking down stories

One of the areas that many teams struggle with is getting user stories to the right level of context.  For me context IS everything in user stories.

 Yes a story is a placeholder for a conversation, but with large complex systems and organizations, the need to build out (and document) context has many benefits for teams and the organization.

Over the years I’ve seen some consistent elements fall out of BDD that can provide teams with an understanding of when a User Story may need to be broken down.

As you begin to build your test scenarios for your user story ensure that the story has no more than 3-4 scenarios.  If the number of scenarios is large, getting a clear contextual understanding of the story becomes much harder.  Additionally if automation is part of the equation then you end up with a larger code base for a single story and it can make trouble shooting failures harder.  Smaller stories mean less complicated acceptance criteria and more manageable and scalable automation code.

Once you have identified your test scenarios and begin writing the supporting BDD acceptance criteria look for some of these elements as queues to potentially break down your stories:

1. Large set of parameters– If you see that you have more than 7-8 parameters in an individual test scenario consider breaking the test into additional scenario(s) or another story.  As I’ve taught my teams, if you see your example table stretching off the page you probably need to break it down.
2. Large set of examples – If you see your test has more than 12-15 examples in an individual example table, you should consider breaking it down into additional scenario(s) or another story.

Keeping your stories and test examples small ensures that the team can more accurately estimate, deliver and demo their work consistently.

Teams should strive to break stories down so that they are small enough to be completed (Dev and Test) within 2-3 days.  This level of granularity provides clear visibility during Standups if the team is on track to deliver on their commitment.

Many teams suffer from what I call ‘pushing a river down a creek‘ syndrome.  Meaning that they don’t perform sufficient planning and story breakdown which leads them to continue to push their work out into future Sprints.  This leads to a lack of visibility as to when ‘it will be done/delivered’

Breaking down stories effectively also leads teams to have stable velocities which leads to predictable delivery.  All of this feeds improved Program and Project management across the organization.

Organizations that need to scale Agile need to understand that this level of discipline isn’t easy, but we shouldn’t shy away from something just because it’s hard.

BDD story breakdown leads to vastly improved feature definition, scalable automation suites and a strong automated regression.

The Agile Manager Conundrum

If your organization is moving towards Agile there are some specific elements you will need to be aware of from a Management perspective.

 Agile focuses on teams being self organizing and what that means for managers is that you need to give up some control, however that doesn’t mean you are backing away completely.

Effective managers in Agile focus on these areas:

1. Technical Vision – This is so lacking in most of the organizations.  Most organizations I’ve worked for have some higher level vision set in place, maybe some standards but at the execution level these tend to ignored in favor of getting ‘it out the door’.  Teams incur substantial technical debt that costs real pain and money to organizations long term.  A good manager is able to set forth operational vision for the team.  Using Scrum processes such as Retrospectives, the manager can encourage the team to come up with processes that work for them that support the vision.
2. Technical Excellence – The operational side of the vision again involves the team understanding what it takes to deliver high quality code.  Understanding how to ensure that code is refactored on a continual basis, that code reviews are not rubber stamps but should have a specific focus and structure designed to teach.  At one startup I worked for code reviews were taken very seriously and provided junior developers with an opportunity to get good feedback on how they were developing as engineers.  As a manager you need to ensure that the Alpha dog syndrome doesn’t happen, good code reviews are educational not demeaning.
3. Career Development – This is probably one of the harder areas for technical managers to be successful in because I think most organizations don’t provide the right type of management training to their technical management staff.  Understanding what to look for and encourage is for me the most important element of being a good manager.  Career development provides the organization with employees who are happier, more focused, more dedicated and produce higher quality results.

No where in these areas do you see the manager handling problems with the teams project planning, etc…  Though you need to build confidence in your teams abilities to deliver, you also need to let the Scrum team and processes evolve so that they(the team) handle most of the day to day issues and keep you in reserve for the important ones that truly need management intervention.

You have plenty to do as an Agile manager, it’s just not what you are probably doing today.

BDD – A team oriented activity

Probably one of the harder elements of Agile that teams struggle with is the art of collaboration.

Our experiences over the years have taught us to treat functional groups such as BA’s, Devs and QA as separate entities each with their own perspective and each distrustful of the others abilities to deliver.  How many times in QA do we hear the phrase ‘Just toss it over to QA and let them deal with it’. 

We forget so easily that what we deliver for a customer is the sum total of our efforts, not just of individuals.  The Chicago Bulls were a good team with just Michael Jordan, but only when they were able to blend ALL of the skills of the team were they able to win championships.  Scrum is about team.

Getting your Scrum team to actually work as a team is one of the key efforts that everyone needs to make and BDD is a way that can help teams  work collaboratively to  build what I call contextually rich user stories.

You can’t rely on just one or two people to write user stories and acceptance criteria as there is a limit to the context of what any one person can know.  With ever growing complexity in business and technology the more people who can collaborate the more context that is captured in the story.

Does it sound like heavy overhead?  It shouldn’t.  I’m sure you have all spent hours pouring over Business or Product Development documents trying to glean enough information to build a design that will work for the next 6 months (which we know doesn’t happen on any planet in this solar system).  We’ve always spent time trying to understand what is being asked for but in Agile we spend smaller increments of time on writing details that matter.

The most successful teams I’ve worked with have adopted this type of approach for building out BDD acceptance criteria:

• Start of Sprint –

1. During the first two days of the Sprint the QA lead and Product Owner work together to develop (and or complete) BDD acceptance criteria for the next upcoming sprint.
2. By day three the development team should start delivering stories to QA for testing.  Additionally QA can begin their automation efforts via BDD examples with tools such as Cucumber, Fitnesse, Capybara….
3. The engineering team needs to plan to complete all of the story development so that the last two days are open for them to  review the acceptance criteria and make changes/suggestions to the PO.  The team is also completing their designs for the upcoming sprint during the last two days and fixing any bugs that are discovered in testing.

The key to this process is that before the team commits to the sprint they must all review and agree to the scope of the BDD acceptance test examples.  Without this discipline, the scope of the story and sprint will not be as precise.

As I’ve told my teams in the past, moving to writing BDD acceptance criteria is a mind shift in how you view both requirements and testing.  Both Development and QA can consume them for their individual efforts, but in the end, if they work against what is defined in the BDD they will both be on the same page functionally.

BDD takes the guess work out of what is being developed and that’s a good thing.  For Sprints to go quickly and with high quality,  teams have to understand exactly what they are doing.  To steal from one of my favorite phrases from Bull Durham ‘Don’t think, it only hurts the ball club’.

BDD provides clarity for the entire team and makes demos go smoothly.

Ensuring that the team provides input, review and commitment to BDD acceptance criteria keeps everyone focused on doing just what is needed.