Some Thoughts on Scope Creep

According to wikipedia (and various other sources), scope creep is defined as follows: Scope creep (also called requirement creep and feature creep) in project management refers to uncontrolled changes or continuous growth in a project’s scope. This can occur when the scope of a project is not properly defined, documented, or controlled. It is generally considered harmful.  

In an agile project, however, sometimes uncontrolled changes can be a good thing.  The whole point of agile software development is to be "agile".  We need to be able to pivot based on market/customer demands/need.  Market needs and trends change regularly, so by doing smaller projects and then breaking those into smaller chunks (iterations), we are able to readjust to get the market/customer what they need/want. Faster. With less waste.  

While uncontrolled changes can be good things in an agile project, continuous growth cannot.  If we are continually growing our backlog, then when will our project be done?  If we continually grow the list of things we are currently working on, then how can we meet our iteration goals or commitments?  Backlog growth comes, but it should be managed for FUTURE releases/upgrades/enhancements.  If the stakeholders really want these extra additions, then expectations should be set and all risks/consequences need to be thoroughly communicated.

How do YOU control scope creep?  Sound off!  

Backlog Grooming

I was going over some backlog grooming ideas with one of our Product Owners recently, so I thought I’d share these ideas with everyone.  

When preparing for sprint planning sessions, please take a moment to make sure the top 20 stories in your project backlog are “shovel ready”.  What do I mean by this?  Shovel Ready means that the stories have advanced to a state that allows teammates to IMMEDIATELY start working on them.  Ideally, this should be done even before Release Planning, but that can’t always happen.  

Here’s how we get them shovel ready:

·        UAC in EVERY user story

o   The team needs to know what the Product Owner’s definition of done is.  Your definition of done is your user acceptance criteria.  Don’t leave this to sprint planning.  We tend to go down rabbit holes as to what DONE actually means.  Product Owners, it is your job to set this standard, and it is the team’s job to tell you whether or not your UAC is possible in the context of the story.  THAT’S what needs to be discussed during planning. 

·        Possible story breakdown

o   Evaluate your user stories so succinctly that you can foresee whether or not they need to be broken down into smaller stories.  If you think you can group certain data flows or business rule variations, then do that ahead of time.  If you are not sure how to break them down, check out Richard Lawrence's How To Split a User Story again .  If you’re still at a loss, then by all means bring it to the team. 

·        Prioritize the backlog

o   Have the most important things you want worked on AT THE TOP of the backlog.  Make sure the team knows this priority, and make sure this priority is reflected in the goals you set for the sprint. 

·        Story Language

o   Please try to write stories in the format of “As a <blank> I want <blank> so that I can <blank>”.  This helps us keep the end user in mind.  I understand technical stories come up, but we need to try to stick to this idea as much as possible.

o   Be very specific in the language of the story.  Make it reflect the end goal.

If you have any other ideas you’d like to share, let’s share them!  Let me know if you have questions, as well.  Each of you have your own awesome style of handling user stories, so I encourage you to learn from one another as well.