When a team is first adopting kanban, they do not typically have reliable numbers for cycle time, and will struggle to make commitments based on a Service Level Agreement. What commitment techniques help during this period, especially when other dependent teams will be at other levels of adoption?
Actually I'd say it isn't dependent on any given method you use. If you don't know how you deal with any given task than, well, it's just hard to say.
A few ideas you might use:
Use any information you have. Like you may have some estimates for some simple tasks done by the team and you may use them as early rough data to use while estimating a new project.
Estimate like you would if you had no Kanban process whatsoever. You would actually do that if you didn't have Kanban in the team, wouldn't you?
Just start working and use whatever information you gather to adjust future estimates so you have your final estimates better and better over time.
Ask other teams which are using similar techniques for help. Ask them how they would estimate such project.
Get used to the thought you will be guessing to some point, you want it or not. Make everyone around aware of that. With no historical data and little experience on similar projects it will always be guesstimate. Don't try to make it anything else.
Actually I wouldn't say Kanban changes here a process - unless you have some reliable data to base on your estimates will base on gut feelings, you want it or not.
Pawel's answer brings great coverage of the subject but as you wanted more thoughts on the subject as I deliver:
- I woudn't expect your new team to beat delivery rates of other teams with higher level of adoption (Kanban and/or work experience) unless you were allowed to hire top guns from outer space.
- SLA's are not everlasting, in fact, there should be some paragraphs about improvements and reevaluations as well. Make first cycle short and meanwhile grab all the measurements experience in estimations.
- If your team is already working on the project then introducing Kanban table doesn't change much in task estimation. New practices do change a lot. I.e: introducing a WIP limit means you can not promise (SLA) too much concurrent tasks but average task work time should decrease. If you suffered from unproper prioritetization of tasks before Kanban then you could probably expect to handle critical tasks better/faster and ofer better quality of service in such area of SLA.
- It is not so bad idea to ask team for an estimation or even a guesstimation of best- and worst-case scenario. You can ask as well for their preference: are they willing to take worst-case scenario, work in more pleasurable atmosphere, but suffer from not so well PR among other teams OR should you take rather best-case scenario and maybe work overtime in order not to break commitments. Make sure it will last only for the first period.
I would add that probably not all work is created equal when considering need for commitment. Take advantage of that. Use the work that is less sensitive to commitment as a sort of "buffer" that keeps you delivering on time, even if you underestimated somewhat.
If all of your work is under SLA, you definitely need to take buffers based on earlier estimation techniques like Pawel described... Some people would say that is a problem in and of itself. I agree. But if you are working at the team level, and you currently don't have enough trust/sway to convince other teams to move more of the work to Pull mode, then you will have first to deliver, then change the reality.