3

As a project manager, I've already worked on a few tech projects with newly assembled teams every time. The team is usually 2-3 team members doing the actual work. It is hard to determine velocity. We aren't really agile and nor do we do sprints.

Usually, we finish the work early or by the end of the quarter. These resources are committed to the work but during the week probably at 70-80% capacity. The rest of the time is to support business needs.

Once again, I have another group of projects with different members in the team. How can I determine roughly when the project will be completed? My 2 developers have put down their estimates for all their tickets.

Improve this question
3
  • 6
    If you "aren't really agile" and you don't use Scrum, then what do you do? The methods by which you can estimate completion of a body of work depend on how you plan and execute on that work.
    – Thomas Owens ♦
    Jul 14, 2020 at 1:21
  • Thanks, I wanted to learn if there are better approaches to come out of this pattern my teams are facing. Mgmt could suggest it but has been holding off since they want to boost profits asap. The teams mentality has been getting things done. I think determining an approximate completion date is hard, because we don't release frequently. More like project by project based and that happens every 2-3 months.
    – user2763930
    Jul 14, 2020 at 17:22
  • In agile we often fix the schedule and vary the scope. If the initial work has added value, then follow up work is discussed. It is a different way of looking at the situation. Sometimes there is resistance to varying the scope by a stakeholder even through the scope always varies as more is known about the project anyway. Just as sometimes there is resistance to giving priorities even though that just means that the developer sets the priorities.
    – Geoff Burns
    Aug 3, 2020 at 12:34

3 Answers 3

Reset to default
1

How frequently will you do releases? One thing you could try is to group tickets into tentative releases (or iterations), convert your estimates to points and then estimate a release velocity / iteration velocity.

Prioritisation and minimising dependencies will also be important, especially if your team are not full time. You tagged your question as Scrum. If you want to move towards Scrum then start with product owners, share a backlog with them and define some priorities. It's a mistake to focus on the "project complete" date because all the important things should generally happen early in the programme of work, never at the end.

Improve this answer
3
  • We release about every 2 to 3 months. Yes, many folks are fixated on a project complete date. They've told me to get estimation from the team and determine the approximate date. Is that even possible? My team (size of 2) believes it takes 20 days to complete. While adding up all of the tasks, it totals up to 30 days. The place here has been running the style of getting things done. I would like Agile/Scrum but it will take a while to get there.
    – user2763930
    Jul 14, 2020 at 16:49
  • @user2763930 , 30 days to "complete" but then you may have to wait up-to two months before you release it? That doesn't sound very realistic but if you are right then your estimation is made very easy. Your estimate only needs to be accurate to the nearest 2 or 3 months because that's when it gets released. So 20 - 30 days seems like it should be close enough as an estimate.
    – nvogel
    Jul 14, 2020 at 19:26
  • Yes, the team surprisingly gives me quite an accurate/close number of when the work is complete. I would like to release or push to prod more frequently though. Mgmt would rather have fewer releases with more things together. I've advocated that this process delivers less value and all the features build a logjam to deliver to waiting customers. Have you ever encountered working on projects with this type of estimation/forecasting style? -In the past, I've worked with teams that are agile and constantly deliver every 2 weeks. Now I am faced with this diff team culture. Thought/view?
    – user2763930
    Jul 16, 2020 at 1:56
0

It really depends on the nature of the backlog/work remaining and the methodology you are using which is not clear on your question.

If you are using SCRUM, you will have to know 2 things.

  1. Story point estimated(story point /= story point estimate) entire backlog
  2. Team velocity given team is performant and team composition does not change.

(Estimated backlog / Team Velocity) * Duration of Sprints + Buffer - Planned Events/leaves should give you a rough number. Remember schedules in agile are educated guesses not actuals.

If its is waterfall, you need to again have 2 things.

  1. Estimated remaining work
  2. Resource assignments.

Based on resource assignments and their capacity you will have to calculate the deadlines which are in most cases fixed.

If the methodology is something like XP, you will have to account release plannings and number of iterations into the calculation.

Improve this answer
1
  • Thanks. My team (size of 2) believes it takes 20 days to complete. While adding up all of the tasks, it totals up to 30 days. At first, I thought creating a 2-3 week sprint would help my 2 resources. We don't release to production after a sprint is complete. We release when the entire project is complete, which usually happens within 2-3 months. The team just started recently but also gets pulled in to do misc. work. So far, what I've been doing is monitoring remaining total number of days to work on all tasks, to determine complete date and add 2-3 wks buffer time.
    – user2763930
    Jul 14, 2020 at 17:13
0

This is hard to advise on without knowing more about the basic lifecycle model, the development paradigm and the methods around estimating. But you do say "we aren't really agile", therefore something like a CBS/WBS should be the backbone of the planning.

  • Write down a list of the product elements / modules.
  • Estimate the effort to get each one to a releasable state. Preferably put in 3-point estimates (q.v) and calculate the sums accordingly.
  • Compare these estimates to what you think your resources can do.
  • Factor in an allowance for system "glue". If you like, represent this as an additional module.
Improve this answer

Your Answer

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

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