I am senior developer/architect who knows the business domain really well.

My new manager wants me to manage a team (yet to recruit of around 5 people) and in the past I have worked in an agile environment but as a developer. So I was involved in the writing user stories, working with stake holders, estimating via story points and all the development work involved in getting to the end of a sprint/project.

I would like to carry on working as a developer and spend most of my time in the depth of writing code but my manager believes only 10% of my time will involved in the management side (i.e. creating product logs, agile estimation etc). He has never worked on an agile project. I am still reading up on all that involved in managing an agile project so it is hard for me to say how much of my time will be involved.

My question is how much of my time will be spent on working on the side of managing an agile project?

This is something I would like to do but I am not sure if I want to do this if I spend all my time on the management side.

  • If all you're doing is managing the team (not interfacing with other departments, not training other teams, not architecting the system, not...) I'd expect ~20-25% - going closer to 50% when you've got new hires. It might help if you qualify the scope of what you're expected to do.
    – Telastyn
    Dec 21, 2013 at 19:24
  • I have a meeting with my manager in the second week of Jan so I would know the scope then. From a meeting a month back, his perception of management (they are not doing agile at all currently) was training others, meetings, once a week meeting with developers to see if they have problems etc. My main role is as an architect. I would love to be more but not at the expense of doing less development.
    – JD01
    Dec 21, 2013 at 19:38
  • 3
    Then I would guess you'll have 20-25% of your time to do development if you're lucky. That said, ask you manager - negotiate with your manager. You're the one who ultimately decides what you do.
    – Telastyn
    Dec 21, 2013 at 20:13
  • Would the time be more or less depending on whether we went agile or not?
    – JD01
    Dec 21, 2013 at 21:58
  • When you say "managing", does that include duties usually assigned to scrum masters, or do you have an actual scrum master helping you out? Dec 21, 2013 at 23:55

5 Answers 5


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).

  • WOW...I think the pessimistic state is what accurately describes the project. I doubt we find candidates with a BDD/TDD background so I will have to get the newbies believing that this is the way to work, whilst at the same time convincing management that newer features won't be out when they except.
    – JD01
    Dec 22, 2013 at 0:09
  • 1
    added a bit more, hope this helps. Dec 22, 2013 at 0:25
  • Thank you Davin. Just to add I wont be the product owner. We have someone in place who has that role. Although I know the domain well, the product owner will work with me to use my knowledge in integrating with a new suite of application the company already have. So in all I would have to take on duties of scrum master, architect and trainer of the new developers.
    – JD01
    Dec 22, 2013 at 1:00
  • 1
    You probably shouldn't add mentoring new developers to your manager time since you will do it anyway.
    – Suor
    Dec 22, 2013 at 2:48

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.

  • Thank you Matthew for your reply, excellently answered,. the breakdown helps immensely. You mentioned obstacles. What sort of areas are you referring to?
    – JD01
    Dec 21, 2013 at 23:52
  • 1
    Personally I think trying to have enough stories to cover the next several sprints is a waste of time. You definitely want to have stories ready for the next sprint, and you should always be thinking about what comes next, but to plan in detail more than a sprint in advance is hard. The whole point of agile is to recognize that change happens all the time, and to be prepared to deal with it. Preparing stories you won't get to for a month or more might be wasted effort as the project progresses. Dec 21, 2013 at 23:52
  • 1
    @BryanOakley - I am not talking about the detail work of breaking down stories into tasks, but rather the higher level estimation of complexity or effort per story. Ideally, a story wouldn't be in the backlog without some sort of estimate, giving management some sort of idea how much effort might be needed to get to an ending point. Part of backlog grooming needs to involve getting this info, and it's work that should be done ahead of the sprint planning meeting. Dec 22, 2013 at 0:27

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.

  • Thanks Bryan. My concern is that the company I work for say they are doing scrum but practically there is not much of it being used (I think they just have meetings in the morning and that is about it). It will be hard to sell to my manager all the areas above you and other have described that I will have to do as their understanding of a manager is a traditional waterfall manager. So when they say I will be doing 20% of my time management related work, I need to understand what they mean by that.
    – JD01
    Dec 22, 2013 at 0:40

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.

  • Thank you J for an excellent answer. It has given me food for thought. I doubt very much my manager will be directly involved in the team, so I would be doing the lead role (involving mentoring others) and doing all the agile project management tasks. I know the domain pretty well so it will be slightly easier for me to talk to the client to and define requirements. Once again thanks for the answer.
    – JD01
    Dec 29, 2013 at 0:46

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.

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