3

Running quite a few short term projects at the moment, and I am not sure how to plan them.

The project set up is the following

  • few resources
  • timeframe of 2-3 weeks.

Scrum does not work well from being capacity based planning, where the data is collected over a series of sprints.

Kanban works slightly better but often I find myself in scenarios where devs are not able to estimate properly forcing me to deliver the project using a waterfall approach given fixed deadline/scope.

What is the best way to deliver a project with a quick turn around that has a tight deadline?

  • 2
    "devs are not able to estimate properly forcing me to deliver the project using a waterfall approach given fixed deadline/scope" sounds like a recipe for disaster. – Alan Larimer Oct 31 '17 at 15:31
  • What do you suggest when deadline is fixed? – bobo2000 Oct 31 '17 at 16:46
  • The timeframe of 2-3 weeks is right in the range of an iteration in many of the agile methods. Is there a reason why you need to treat these as individual projects rather than one project with a few different tasks? Things like Epics and Themes are often used to group backlog items (Stories, Tasks, etc.) into common threads. – Thomas Owens Oct 31 '17 at 17:18
  • 1
    Build in lots of slack (i.e. pre-deadlines) and be realistic. The core work should be done in 2 weeks to allow for a reasonable way to finish thing. Unless your team likes working lots of overtime. – Alper Oct 31 '17 at 18:59
  • 1
    Not sure why this was downvoted. It's a perfectly valid question because it happens all to often in real business. – Joel Bancroft-Connors Oct 31 '17 at 19:13
3

It will be difficult to provide you a comprehensive answer, there are just so many potential variables. Let me see if I can address a couple of things.

Kanban and estimating: Don't. Kanban's value is in setting up a continuous flow of work. Prioritize the backlog, break work into the smallest valuable pieces and have the team pull the work from the top of the backlog. Limit work in progress to focus on getting things done. Once you get into a flow you will start to see cycle time trends which can be used to figure out what can get done by a given date.

Sprints and data over time: If each project is truly unique I can see some issues. I'm betting, though, that project to project have similarities (same code base, same general application, etc). If so, you can use past sprint data of a different project to plan for sprints for a new project.

Fixed Scope/ Fixed Deadline: This is your key issue. As long as the business thinks this is possible, then you'll never progress out of fire fighting project work. The only thing that happens in an FS/FD project is quality suffers. Then, over time, you will end up spending more and more time on fixing and less on building.

Unfortunately, we will never get away from Fixed Deadline. It's just not in human nature to not latch on to a date as "ship". So you have to focus on getting the development org to predictability (cycle time, stable velocities) with similar sized stories. By doing this, the team can reliably say "We can do X work by the release date" and have the data to back it up.

Good luck.

  • How do you estimate in Kanban? I know there is cycle time, but the only issue I have with it is where you find out how long it takes to complete a task after it has been completed. This has created problems in the past 'it will be done when it is done' mentality without any estimation. WIP limits only tells me how many tasks can be done at one time. – bobo2000 Nov 2 '17 at 10:06
  • @bobo2000 Without a stable situation (team, project, tech) it's going to be difficult to provide predictions with any degree of confidence. Since the projects are necessarily short here, focus on keeping the rest as stable as possible (within reason). Beyond that you simply have to accept the uncertainty and make sure you don't spend more effort for estimating than the resulting output is worth. What problems were created under the previous it's done when it's done mentality? No amount of estimation will make the work be completed faster... – Kempeth Nov 2 '17 at 12:50
  • "What problems were created under the previous it's done when it's done mentality? No amount of estimation will make the work be completed faster..." true, but without any estimation people feel like they have not committed to delivering under time constraints. – bobo2000 Nov 3 '17 at 10:09
  • 1
    You can estimate in Kanban the same way you estimate in Scrum. All estimating is, is a team fiction of how big they think something is so they can compare it to all the other things they are doing. The issue you're describing has more to do with accountability and tracking. A good standup, with small stories or stories broken into small tasks is a better way to get to done. An estimate won't help when it's late. The dev will just say "our estimate was wrong." – Joel Bancroft-Connors Nov 3 '17 at 23:04
  • @JoelBancroft-Connors what metric do you use to estimate in kanban, hours or points? – bobo2000 Nov 13 '17 at 12:02
2

A few things I've found to work in similar situations:

  • prioritise work and use Kanban to do as much as the prioritised work as possible in the fixed timeframe
  • don't use estimates at all but try and get developers to break tasks down into the level of detail required (by setting rules such as no ticket should take longer than a week for example)
  • don't give a specific ship date, but focus on a date range (use w/c for example and that gives you a fair amount of wiggle room for such a short project cycle)
  • use daily standups but also keep a close eye on the board yourself, if something is not moving ask why early

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.