2

We are currently using Scrum and we are evolving into Kanban. At the same time, we are starting a migration from version 1 of our underlying framework to version 2. There is a target date of January 1 for this migration to be complete. This date is not exactly set in stone, but it's a goal that we'd like to meet in order to add new features before our busy season next Summer. Right now I'm trying to figure out how much development effort that will take.

I'm all for the "decide late and deliver early" approach of agile, but I need to figure out if we'll need more developers and how much work it will take to complete this project.

What are some metrics I can use to figure out how much development work will be required for this project? How does this work with Kanban?

Improve this question
2
  • To figure out how many developers we'll need and how much time it will take to complete the project
    – Joshua Dickerson
    Commented Jul 31, 2017 at 22:31
  • I encourage you to look at this video from 11:28 to 14:22 youtube.com/watch?v=502ILHjX9EE - also, be careful about assuming that adding developers will make the work get done faster - as the old saying goes "Adding people to a late project makes it later". Adding people can help, but it usually isn't a simple relationship and it needs time before it has a positive effect rather than a negative.
    – Daniel
    Commented Aug 4, 2017 at 9:40

2 Answers 2

Reset to default
3

Kanban is just a visualization tool, in itself it cannot provide metrics. Based on your experience to date do you have an idea of your teams velocity or capacity? That will be the only thing that will help you estimate your manpower requirements for the Jan 1st deadline.

Regards

Improve this answer
2
  • We have velocity, but Kanban is different than Scrum in that we'd be using cycle time. Cycle time is a hard metric to use to figure out how long it will take to complete the project.
    – Joshua Dickerson
    Commented Jul 31, 2017 at 22:32
  • 1
    Apologies, cycle time is what I meant. So (Cycle Time) * (No Of Resources) * (Size of the project) = No of working days required to complete the project. .... So the difficult part here is splitting the project up into the bite sized chunks that your team can turn around in their typical cycle time. That's where the experience of your team and the software your developing come into play. Alas Kanban has nothing more than that in its metrics to help you out.
    – Andy L
    Commented Aug 1, 2017 at 7:26
2

I really think you're falling into "give me a date" -trap here. Basically you have no idea how long it's going to take until you start implementing and learning. So, what you should do is give an interval with some kind of confidence levels.

Then you start doing the work, you get your first cycle times and estimate how much time you have left and update your estimation for the whole product. The truth here is that no one knows how long it's going to take and you should communicate that clearly. "It will take anything between X and Y months and we are constantly updating our estimates as we learn more".

Improve this answer

Your Answer

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

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