« But I’m a Great Leader! Look at My Results!
Is Your Project In Trouble? »

Managing Technical Scope

April 12, 2012 | Author: PM Hut | Filed under: SCRUM

Managing Technical Scope
By Neil Killick

We had a bit of a debate the other day in our team about how to deal with technical scope in a Scrum project, so I thought I’d write about it to try and explain.

As we all should know by now, Scrum focuses on delivery of business value. If a requirement does not appear to deliver a recognisable benefit to an intended user of the system then it does not generally make it onto the Product Backlog (or at least it won’t make it into a Sprint Backlog and be implemented).

The implementation of requirements (as user stories, in our case) will typically include technical tasks such as setting up a database or writing code, so when we estimate the effort involved in delivering the business value we (should) take into account the technical component of that effort (including technical risk and uncertainty). For this reason, if we identify a purely technical task that does not deliver value within a particular user story then we do not include its implementation in our velocity measures. Here’s why: The scope of the project in story points equals the estimated effort to deliver the system as usable software for the business. This means that all of the technical effort required to deliver the software is implicit within the estimations. If we started artificially increasing scope with purely technical tasks it would give a false barometer of the project’s boundaries because those boundaries are derived purely from business requirements.

Remember we do not measure velocity in order to track how much work is getting done. We measure it to help us plan how much work we will do in the future. There needs to be a balance in some Sprints where the Product Owner allows important technical tasks to be worked on, thus reducing the amount of pure business value that can be delivered in the Sprint. Rather than saying “hey, we’re still delivering 20 points because we did a 3-point technical task”, in the spirit of transparency and a true representation of our progress we say “we delivered 17 points of business value”.

The same applies for defects. Defects are waste. They are not part of the scope and so should not be included in velocity measures. Defects and technical tasks should still be estimated in order that the team knows how many fewer points they will be able to deliver in the Sprint, but they do not count towards the progress of completing the product.

Neil Killick is a highly skilled I.T. professional with 17 years of varied experience in England and Australia. His background is in Java/Web development, but his more recent experience has encompassed being a ScrumMaster, Iteration Manager, Senior Agile BA and Product Owner, as well as a Team Leader, Coach and Mentor in Agile or transitioning environments. You can read more from Neil on his blog.

Share this article:
  • Digg
  • del.icio.us
  • Facebook
  • Google
  • blogmarks
  • LinkedIn
  • Reddit
  • StumbleUpon
  • TwitThis
  • Yahoo! Buzz

This entry was posted on Thursday, April 12th, 2012 and is filed under SCRUM. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

No comments yet.

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

All fields marked with " * " are required.

The Stevens Enterprise Project Management Master's Program

Project Management Categories