3

Like most things, it depends. In theory, you could forecast when work is likely to be done. If you understand your team's average velocity (whether it's in story points per Sprint, ideal hours per Sprint, backlog items per Sprint), you can forecast when you will get to a particular item on the backlog. However, there are a lot of caveats with this. It ...


3

You have two separate problems here. You are not on the same page as your VP on what 'agile' means. You think it's the VP's place to decide whether or not a timeline is realistic. I'll tackle these in reverse order. Realistic vs. Acceptable Estimates First, the only one who can decide if an estimate is realistic is the team doing the work. The only one who ...


2

I wanted a little more background, and by reading your other posts I see that you are/were a product owner for a group of 10 developers. I will answer assuming that this is still true, but the answer will be much the same if your position has migrated to a project manager within DevOps. It just means you will work with the current product owner to provide ...


2

The tool you want is a burnup chart. JIRA has them built in as Release Burnup Chart or Release Forecast Chart (they keep changing the name), but the feature in JIRA is limited that it only forecasts the whole release. However, you can build these charts by hand - they may seem difficult at first, but they're very fast and very easy once you get the hang of ...


1

Are timelines non-agile/-SCRUM or should a timeline be always possible for tasks that are months in the future. You can always do a long(er) term release planning no matter if you use Scrum or anything else. You basically look at the features you want done, estimate each and every one of them, then knowing the team's velocity and the length of a sprint in ...


1

Most likely, the source(s) of this question is highly suspect. I would doubt this type of question would ever find its way to the real PMP exam because the "best" level for a stakeholder depends on the type of engagement you need from that stakeholder segment. Therefore, there is no such thing as a "best" level of stakeholder engagement ...


1

You won't be able to use Word documents effectively within a git repository. You could use your repo to check in the Word document file and version it, but you wouldn't be able to do diffs or handle merge conflicts. It could even add overhead to the team, depending on who has the right access permissions and knowledge to be able to use git to control the ...


1

Honestly, I'd be cautious about the idea of "training" business owners. You've really just got "a classic salesman's problem." How to convince people that your approach does have merit, that it really will reduce costs and business risk, and that you actually understand their point-of-view. (Which is necessarily altogether different ...


1

Who should train business stakeholders very short answer: Someone who has the knowledge and a hint upfront: It is not only that they should be trained, they must be motivated to do the "new" part of their work and as always with "new" work, nobody wants to earn new workload. Now the longer and explanatory part: I have no idea which ...


1

You didn't say what kind of projects these are. If you are talking about software, data and technology work then generally it is better to focus on products and value streams rather than projects. In software, projects tend to matter very little and the product is what your business stakeholders should be (and probably are) focused on. As Tiago suggested, ...


1

This is a systemic problem, and although you may support business stakeholders to understand what prioritisation means, you will definitely need senior management support. In your case, you mention you have joined the project to stablish a prioritisation method. That's a demonstration that senior management is aware of the problem (which in itself is a big ...


1

Estimates and velocity are the answer to your question. Nothing about Scrum stops the team from estimating work (and it should be the team who does so, not any one person). The scrum approach helps with estimation and scrum teams normally base their forecasts on velocity (evidence based on previous results) rather than any more speculative predictions.


Only top voted, non community-wiki answers of a minimum length are eligible