BLOG

  • blog_img
    • 24 August
    • No Comments
    • View

      (129)

    Is there Scope Creep in Agile?

    Well, the short answer is NO.  Why?  Because if the team as a whole is executing the way the Agile founders designed, the focus should be on completing task within story within sprint, BUT adaptable and open to change.  The team as a whole should be selecting the stories to be developed based on priority but also readiness while (in turn) understanding story requirements are not frozen.

    However, some of what might be occurring within the team causing it to deliver in-efficiently could be interpreted as scope creep.  If there’s an agile coach on site, he/she must pounce on this.  The cause can even be the waterfall (like) execution of the Agile framework selected by your organization.

    We need to hear why scope creep is the perception?  It’s important for the coach to inspire the team by saying not only are they (the developers) really good at what they do, they are the ones closest to and the ones doing the actual work.  Therefore, if what they’re experiencing appears to be scope creep, then we as a team need to have that discussion and get this resolved before the next planning session.

    Do we understand the stories we selected during sprint planning?

    I mean end to end really understand them?

    Are the developers closely coupled with the product owner?

    Can the story be completed in this sprint?  Will the acceptance criteria be met?

    Is the Story even testable?

    We’re ALL OF YOU GUY’S involved in the estimating of the story (or stories) selected in this sprint?

    Are the stories “ready” to the point that developers can begin (what I refer to as) hands down coding; no need to revisit, re-evaluate, redefine, or begin high level design of the delivery effort….just start coding.   Do you (as a team) even have a definition of ready?

    Is there any outside commitment needed but not obtained; yet the story has been selected as ready?

    Do we (as a team) understand each sprint will be delivering tested software?

    Do we (as a team) understand we have approximately 8 days of development, when you consider day 1 (for the most part) is planning and day 10 is Sprint review/Demo; assuming we’re doing the recommended 10-day Sprint.

    Have we (as a team) created test case within task within story, so we can actually test and prove what we’re developing is “done” based on our definition of done (predefined as a team).

    Do we as a team understand (based on the Product backlog priority) we’re delivering what’s needed most…next?  And because of that, our seniors can’t wait to see what’s being delivered next!

    The agile coach must get to the bottom of this if in fact your team is concerned about scope creep.

    Again to be clear there is no scope creep in Agile.  If scope creep is being mentioned, call time out and have this conversation.

    Agile is a shared leadership model and shared leadership is a faster, smarter and more efficient way to deliver tested software each and every sprint with less risk!  There is no place for scope creep in agile.

© Copyright 2017 - Charlie and Eva

Designed by : Web Strategy Plus