9

Team is starting on their first capital-A Agile project, and the project seems like it will fall in line nicely with the methodology (i.e. we can probably just grab an agile book and follow it like a recipe), with one bit of confusion:

The project involves three things that nobody on the team has any experience with: Integrate with the Foo Payroll System, be able to handle the file type XYZ89 (where "XYZ89" = some file type you've never heard of), and convert some other files so they can be handled by the Frobnobdicator.

As I understand it, standard Agile practice would be to schedule spikes for each of these, after which we can determine how long they're going to take (I'm not sure there's much of a chance that the client will decide not to do them, as they're pretty much solid requirements of the project)

So my questions are:

  1. Do we do all the spikes up front in the first iteration to get a better estimate of the time it's going to take to do them and/or get a "walking skeleton" up and running?

  2. If not, wouldn't the total project schedule be at the mercy of one of these spikes coming back with data that this particular story will take way longer than we ballparked?

What is the best practice way to handle multiple spikes when they are basically non-negotiable requirements of a project?

Improve this question

3 Answers 3

Reset to default
4

The way I have handled these shady unknowns in my project plan before is to try and setup time for the development team to do prototypes of the unknown functionality before hand. This gives the benefit of making clearly known what will be required to do the specialized tasks, proves that these are technically feasible, and educates the rest of the team on the possible pitfalls to avoid when active development starts.

This is why many Agile projects usually start with a, what I like to call, Sprint 0.

Think of it as lacing your running shoes, stretching, and putting bandaids on your nipples right before you start a marathon. This time can be used to do the initial project planning and user story creation, design and architecture rollout, software framework creation and the developers can work on any prototypes and proof of concepts for any new technology or unknown technical challenges that will make user story point estimatation much easier.

Improve this answer
1
  • 1
    Bandaids on the nips are an absolute must! And so is Sprint 0 for all but the most trivial and lowest risk projects!
    – Michael
    May 11, 2012 at 13:43
3

You should be doing things in the order of the priority set by the product owner (or customer). There's no sense in killing yourself over something that was really a nice-to-have. The idea is that if you run out of time and something doesn't get done, it should be the lowest priority items.

If they won't prioritize what they want, you are going to struggle.

If things are relatively equal, do not start with the hardest item--start with an easy win, which will give the team a chance to get used to working together using the new methodology and the customer some confidence they can deliver stuff this way. Once that's established, tackle something difficult. Measure the complexity of the difficult item against the complexity of the easier stuff you just did, and you'll start to get an idea of how long it may take to get through it.

Complex items aren't really "spikes". They are simply things that take more effort to figure out. Break them down into simpler tasks as much as you possibly can.

Improve this answer
7
  • 1
    I think in this case they have to be spikes, because nobody on the team has ever worked with the Foo Payroll system, XYZ89 files, or the Frobnobdicator before. We have no idea how long integration with those systems will take.
    – user53737
    May 10, 2012 at 15:27
  • @Jordan - I get that, but if you base your estimates around a complexity model, as opposed to an hourly model, you can get a grip on what it's going to take. Yes, you've got a learning curve on file formats and APIs--a little more complexity. Yes, you've got to work with the Payroll folks--a little more complexity. That may mean that you can only work on one of those items and nothing else in an iteration.
    – Matthew Flynn
    May 10, 2012 at 16:03
  • 1
    I'd highly recommend looking at Mike Cohn's User Stories Applied (amazon.com/User-Stories-Applied-Software-Development/dp/…)
    – Matthew Flynn
    May 10, 2012 at 16:05
  • 1
    Oh sure, I understand the value of estimating in terms of relative complexity as opposed to hours. The part I'm confused about is if this approach were correct for the situation I've described, it would seem that spikes wouldn't ever be used on any project (the devs would just say "eh, that seems like a 3, this seems like a 5", even though nobody knows anything about integrating with the Fizzbot System)
    – user53737
    May 10, 2012 at 16:08
  • Well, my hope is that if nobody knows about Fizzbot, they'd say it seems more like a 13 or a 21, and then break down the tasks--1. learn something about Fizzbot. 2. Build basic Fizzbot access. 3. Model case for real Fizzbot use. 4. Build integration tests. 5. Build real Fizzbot integration... You know, break down the pieces into stuff that are understandable and hopefully bite sized.
    – Matthew Flynn
    May 10, 2012 at 16:18
0

A possible solution is toy create a task for doing a proof of concept to figure out how to solve the problem and time box it, then add that story in to a sprint with other stories.

You are sill delivering value and a product at the end of the sprint, even if it's a hack console app. The idea is you're not sinking the entire team's productivity, if you run out of time, you add another similar task to next sprint.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.