I think it heavily depends on the nature and current state of the project:

Optimistic:
All of the new (5) developers joining the team will be from similar domains and instantly grok the challenges in the features you are building. Since you understand the domain and the architecture (and the project is not too large), you can easily answer questions about it without drawn out whiteboard sessions etc. Plus the system is written very well (using TDD) and fully documented.

Pessimistic:
Over the years, the system has been has been built by several teams and each team thought they were following their best practice. This means that the code base now has several strategies for solving similar issues. Also, the project management up to now has centred around pushing out new features fast, so the technical debt has stacked up. Also, unit testing has always been an after thought. Adding to this, the domain is very niche and all the new developers will need extensive training before they will understand parts of the domain.

So, in the optimistic scenario, you probably could be coding alongside the new developers fairly quickly. The only main issue is personalities and working behaviours as the team forms into a cohesive unit. While in the pessimistic scenario, being the main link both for the domain (business) and the architecture (technical) you will be having extensive conversations and writing a lot of wiki entries or documentation.

You can probably see where this is going, something like, “Hope for the best, plan for the worst”.

Having been in a similar situation in the past, I would say that you shouldn’t plan on coding at all for at least 4-6 months. Taking on the responsibility for both the architecture and business link for a large project can be a lot of work (even for a team of 5). This doesn’t mean that you won’t be coding at all. However, the times you are coding should be interrupted frequently by people asking questions. (You might want to look into things like Pomodoro Technique etc)

Ok, now a few more things with my pessimistic hat on. 🙂

Your manager says it will only take 10% of your time. So, that roughly equates to 4 hours a week. If that is the case, why does your manager not just manage the project? Probably because he or she knows that it will end up taking more time then that.

As developers, IMO, we tend to severely underestimate good management. Now, SCRUM is far from perfect, but there is a reason why 2 of the 7 full time jobs go to managing (scrummaster and product owner).

There are several things to consider in determining this stuff:

• estimates: these should always be bottom up–if you do a user story approach, figure on having a regular meeting with your team and SMEs sometime near the end of each sprint to update your product backlog with estimates for enough user stories to cover the next several sprints. Figure on a 2-3 hour meeting for this in early sprints, maybe going down to an hour in later sprints.
• administrative tasks: try to spread (diffuse) the pain as much as you can that is, delegate if possible, perhaps having a different team member do X each sprint. Have a task board that the team can update throughout each sprint.
• enforcement: that is, making sure the team is helping with estimates and updating the task board. This will take more time to start, then become trivial.
• training/mentoring: you’ve got to do as much as the team needs. This is very hard for an outsider to judge.
• removing obstacles: this can be a full time job, depending. Is your manager helping with this?

So, you should probably let your manager know that initially, you’re going to be spending 25-50% of your time getting the regular flow of the project into gear, along with some amount of time training/mentoring. Hopefully, after a couple months, this will be reduced to 10-15%. The real question then becomes how much support you will get removing the obstacles the team runs into. If you’re on your own there, you will not be doing any coding.

I was a software architect who transitioned to being a technical product owner for a team. In my experience, I needed to spend a good 25% of my time or more working strictly as product owner. It took a surprising amount of time to do the job right, and when I didn’t, it affected the team.

Some weeks I spent 50% of my time, or more. It’s hard to say for certain, because I also acted as architect — this let me cut out the normal PO/Architect meetings since I was just meeting with myself. Between being the architect and being the PO, I rarely spent more than 6-8 hours of coding a week.

Don’t forget that grooming the backlog and keeping it up to date takes real time and requires real thought. It isn’t just a little extra work you have to do. Also, preparing for sprint demos and retrospectives takes real time as well. For me, on demo days my time was 100% spent on non-coding activities, and the day before a good 50%-75% or more.

So, here’s one bit of anecdotal evidence that says you’ll need to spend at least a quarter of your time, and possibly more depending on your organization, your team, and the product you are building.

As others have stated, there are a lot of factors at work here. I guess I’d like to start by trying to make a list of which ones I think will affect your time the most:

• Where does your company draw the lines for project management? For example, is your manager some form of a project manager that you expect to be heavily involved in driving the project management or does all of that fall to you? The more they are involved, the less time you may have to spend – to a point. The fact that your manager thinks this will only take 10% of your time strikes me as one of three things: 1) he is indirectly communicating his level of involvement – which would be quite a bit, 2) he is new to the role of manager and may not be communicating realistic expectations, or 3) he is trying to offload work to you and this is his way of convincing you.
• How well-defined is the project? If you are joining the project with well-thought out requirements in-hand, that is quite different than joining in the early stages. Who’s managing the requirements document? If it’s you or someone on your team and not your manager or some other person, that’s a good litmus test of the expectations for you and your team.
• How decisive is the customer? How needy are they? Some clients (if this is an external project) can be quite needy and demand lots of time. Again this also comes back to how management is divided in your company. On a similar note…
• How many different customers are involved in the project? If it is just your company and the client, great. But if there are other entities like say, an external design company, prepare for a lot more communication churn.
• Is the end size of the team you plus five others? One team lead at my work place goes by the rule of thumb that he tends to go to almost 100% management time once he has at least four people on his team. For me it would probably be about 80% with four, but that largely depends on your team as well – so getting to that…
• How experienced are the people joining you? If any are new hires, my gut says 10% of your time for each new hire should be set aside for at least a few months. For anybody straight out of school, make that 20-25% per person.

So to review from a high level. The agile project management truly doesn’t take that long, but I personally find it highly unlikely that that is all you will do in this role. I suspect that you will also be a leader that helps mentor and guide your team as well as possibly a customer liaison. So the agile project management could be done in perhaps 10% of your time (although 15% at least sounds more reasonable). But for the team lead part alone, expect 25-75% of your time depending on circumstances. For customer liaison, that’s extremely variable based on your involvement and can be anything from 10% to nearly a full time job. On the whole, I find your manager’s suggestion of 10% like a lowball answer. Please evaluate question #1 very carefully and act accordingly.

If this is your first opportunity at having a chance to lead, I recommend taking it. I think a lot of technical folks (but certainly not all!) are surprised by how much they like the technical lead role – I know I thought I wanted to hide in a cave and code but the reality is that I have found being a team lead to be a fantastic experience.

It’s possible it will only take 5%.

I am basing it on my experience in a following setup: 2-week sprints, planning takes half of a day, demo + retro take half of a day, daily scrums – 15 mins each, full code review. All these you would do anyway as any team member so we shouldn’t count them. Here are things that will differentiate your position from simple senior:

• prepare for planning (ensure backlog is in good state, with all the fields filled in, print cards, secure a meeting room, gather everyone) – about 2 hours
• fill scrum board after planning (reprint cards, prepare burn-down diagram) – about 1 hour
• prepare for demo – almost no time, you can arrange that everyone prepares his/her part.

And a couple of things that you should estimate yourself:

• interacting with project owner, support, designers, etc. In prefect scrum you do that directly only on planning and demos and use project backlog all other time. In practice you will occasionally talk to them during sprint.

• shielding your team from managers, support and project owner. Ideally, these guys should not interrupt you during sprint, but they will, so you need to listen to them and either ask them to add whatever they are talking about to backlog or add an new urgent task to your board.

Both things become easy and not time-consuming once you educated everybody to respect your process.