High level estimations of the PBI's - agile vs traditional project management

I would consider why the CEO needs a project timeline to begin with. Is he trying to make a go/no-go decision on the effort? Or trying to make commitments to external stakeholders? Or something else entirely?

Any "freshly baked" team is going to have trouble estimating. They are still going to be going through team formation, developing habits and practices and finding ways to work together effectively. They aren't going to be able to estimate effectively in any units until they have some kind of baseline. Even a more broad estimation method, like t-shirt sizing, is not going to be extremely reliable.

You may have some good opportunities for education here.

If you are following an iterative development model, like Scrum, you are effectively funding many, many small projects one after another. Each Sprint is a project. Every Sprint results in demonstration, if not delivery, of working software. If the investment in the project is not resulting in the value that is needed to warrant proceeding, it can be terminated after any Sprint. In addition, nearly every traditional project has change control built in, and it's built into iterative development as well, but as part of the standard process rather than exception handling, which enables continuous learning.

So, rather than investing time in trying to estimate and plan, invest that time in understanding and decomposing the work and starting to demonstrate and deliver working software. Get started faster, get results faster, and make the decisions based on actual effort. Within a few Sprints, your team may be able to start to provide some rough forecasts based on the ordered Product Backlog.

the team is new so there can't be any predictability made by using velocity

What kind of evidence does management expect the team’s predictions to be based upon?

Hi Ian, 

 

What kind of evidence does management expect the team’s predictions to be based upon? 



That's the problem, management expects that predictions are based on ''gut feeling'' and on previous experience on other products, however, as I said, the team is new so there is no velocity.



Hi Thomas,

I would consider why the CEO needs a project timeline to begin with. Is he trying to make a go/no-go decision on the effort? Or trying to make commitments to external stakeholders? Or something else entirely?



The project needs the timeline because the CEO wants to know if the team can finish the project in XY months that are already planned for go-live. Based on these estimations, further predictions will be made regarding the go-live moment. Good thing is that we already done story mapping with the team and pretty much decomposed the US into sprints (to make it iterative and to produce working product increment). However, what my concern is that I am not sure how to avoid situations whereas the team is ''checking'' every US and estimates it in days. I believe that's not agile and that's not the idea! But I still don't know how to handle management in this particular case...

The project needs the timeline because the CEO wants to know if the team can finish the project in XY months that are already planned for go-live. Based on these estimations, further predictions will be made regarding the go-live moment.

How many months is it and what is your Sprint length?

Rather than spend more time and resources creating a detailed timeline, I would propose giving the team 2 to 4 Sprints that are 2 weeks long - that's a month or two of design and development on the work. In that month or two, the team will do several things - demonstrate progress through working software every 2 weeks, reorder the Product Backlog based on the things they learn and stakeholder feedback, and continue to refine the work that is known to give high level projections and forecasts (not estimates or commitments) of when the known work will be completed.

Good thing is that we already done story mapping with the team and pretty much decomposed the US into sprints (to make it iterative and to produce working product increment).

This does not seem right to me.

You shouldn't have Sprints planned in advance. You'll run into a few problems. First, if the team doesn't complete all of the work in one Sprint, this will have a ripple effect on every other Sprint down the line. Second, your plan can be negated by stakeholder feedback based on work done in a Sprint - some work may be removed, others may be deemed to be more important or a higher priority - again rippling through all of your planned Sprints.

Instead plan one Sprint at Sprint Planning. The Product Owner should be maintaining an ordered Product Backlog and whatever is at the top of it should be well-refined by the Development Team, ready for being pulled into a Sprint. Reorder it regularly based on stakeholder feedback, but especially reorder it at Sprint Review.

Also consider that the User Stories that you have are most likely wrong. Not that they don't align with what the stakeholders want, but what the stakeholders want and what the stakeholders need are not the same thing and they don't know what they need. Regular demonstration and use of working software helps stakeholders to focus in on what they really need. You may find that some of the things specified up-front are not necessary and can be removed while there is work that was not specified up-front that must happen to make the deployment a success.

However, what my concern is that I am not sure how to avoid situations whereas the team is ''checking'' every US and estimates it in days. I believe that's not agile and that's not the idea!

I don't like estimating in hours or days, since it's usually wrong. Unless you make it clear that it's ideal time rather than calendar time. Ideal time considers just sitting down and working on the thing without interruption, continuously, until it's done. But you have to recognize that there are interruptions and calendar time is going to be different than ideal time. I would advise against estimating in calendar time, ever, since it's incredibly hard to conceptualize interruptions and context switching and other factors that cause ideal time and calendar time to diverge.

But I still don't know how to handle management in this particular case...

This is a teaching opportunity. Agile has its strengths that are more closer aligned to the realities of software development. Defining a full set of requirements up-front, trying to stabilize them, and developing a long-term plan is very risky and increases the chances of failure. Prioritizing requirements, stabilizing a small number, and being highly responsive to feedback increases the chances of the stakeholders being able to either get value for their money or to cut their losses when things go terribly wrong.

That's the problem, management expects that predictions are based on ''gut feeling'' and on previous experience on other products, however, as I said, the team is new so there is no velocity.

Have management communicated what they will do when unevidenced time-based predictions turn out to be wrong, possibly by several orders of magnitude?

Instead, plan one Sprint at Sprint Planning. The Product Owner should be maintaining an ordered Product Backlog and whatever is at the top of it should be well-refined by the Development Team, ready for being pulled into a Sprint. Reorder it regularly based on stakeholder feedback, but especially reorder it at Sprint Review.



Yes, this should be a regular case and this is what I do with the other teams. The challenge with this team is that the X team depends on the Y team that delivers the X team its API. And, the problem lies in here: THEY ALREADY MADE THEIR TIMELINE, and present it to team X. So, basically, PO doesn't have a really ''open book'' for proposing the PBI's for the sprint that is coming. Because the Y team made their timeline than also the X team needs to make their timeline according to the Y team timeline. However, the Y team is not Scrum team and they do sprints but, if needed, they can easily increase the number of their development team, but the X team is a Scrum team and it is already established their number.



I am not sure if you can follow what I am saying, but that's the case and it's pretty abnormal. 



Regarding the sprint length, it's two weeks. Regarding the months, it needs to be done by March. 

 

Has management communicated what they will do when unevidenced time-based predictions turn out to be wrong, possibly by several orders of magnitude?



No, they didn't, but that's a good argument for challenging their need to estimate all PBI's upfront.