Please login or join to subscribe to this thread
You have to remember that agile approaches are predicated on a changing scope. The point of creating timeboxes, is to avoid managing your project at the level of scope items.
On my last project, I did not try to manage scope with my project schedule. I only managed iterations.(Granted, my project had 8 Scrum teams for 3 years...)
If that is not an option for you, consider splitting unfinished work from the finished work and reporting it as a separate work item in your next sprint. (I would strongly suggest you ensure that work items are broken down as fine as possible to avoid this. I aim for work items that take a single day.)
I don't currently have access to Project so I can't doublecheck this, but I have used the Sprint features in Project. I'm pretty sure you can change the start date of the tasks/subtasks that get moved to the next (or future) sprint. This can mess with EVM if you're trying to be precise on the percent complete of the tasks/subtasks, but from a story point/velocity perspective, none of the points from the tasks/subtasks that were moved would count in the original sprint.
I would ask if you are using AgileEVM or traditional EVM, but I'm not sure Project is set up to handle AgileEVM. It would be manual work, but might be worth looking into to determine if it is a better fit for the context of the way work is being done.
As most projects will have some scope or work which is not delivered in an agile manner (e.g. training documentation done traditionally, software built in an agile way), an integrated project schedule using a traditional scheduling engine such as MSP is still common.
However, the level of detail for agile work streams is higher. I would recommend against any task lower than a sprint (if you are follow an iteration-based approach). X number of sprints linked together will end in a milestone for a given release.
The benefit is that where there are dependencies between traditional and agile workstreams or external dependencies the team has, those can be effectively captured.
There are others, here, that know more about AgileEVM than I do - I think Kiron might be one of them. I haven't used it, but the idea is that it uses Scrum data points as inputs to the traditional EVM calculations and metrics. Here's an article from PMI:
We're discouraged from posting external links here, but the Microsoft Project User Group (MPUG.com) has some information on this, as well, and you may find people using it.
The downside I suppose is I lose tracking of earned value and other data at the iteration level from summary tasks
Please login or join to reply