I am part of an Agile scrum team working on a software product release. The sprint duration is 2 weeks (~10 days).
There is a peculiar metric used here, called 'mid-sprint acceptance'. Essentially, the expectation is that half the user-story points committed and planned by a scrum team in a sprint needs to be completed by the middle of that sprint. This, they say, results in a linear burndown of points which is a strong indicator that the sprint is going on well.
As a team, our mid-sprint acceptances are usually bad, but we are known to complete all the committed user-story points by the end of the sprint.
I have the following questions:
1) Is mid-sprint acceptance a valid Agile/SCRUM practice? Is it being used anywhere else?
2) Expecting half of the work to be completed in half the time is akin to treating it as a 'factory-floor' job, where the nature and complexity of the work at hand is completely deterministic. Since software development is a 'creative' process, such rigid metrics in a highly flexible methodology such as Agile is irrelevant. What do you think?
3) Although my scrum team completes all our commitments just in time for the sprint, we are being questioned for our bad mid-sprint acceptance metrics. Is it completely normal in scrum teams everywhere else to meet their commitments only towards the end of their sprints?
Much thanks in advance.
1) Is mid-sprint acceptance a valid Agile/SCRUM practice? Is it being used anywhere else?
I have not heard of mid-sprint acceptance before. I dont believe it is a valid Agile/Scrum practice. This site would appear to agree "Once the team commits to the work, the Product Owner cannot add more work, alter course mid-sprint, or micromanage."
2) Expecting half of the work to be completed in half the time is akin to treating it as a 'factory-floor' job, where the nature and complexity of the work at hand is completely deterministic. Since software development is a 'creative' process, such rigid metrics in a highly flexible methodology such as Agile is irrelevant. What do you think?
Any rigid metrics are generally not a good idea to use with developers for the reasons you mention. Also for the likelyhood developers will be more interested in getting a pass mark in whatever is being measured and not in producing a quality product. This is one of Joel Spolskys bug bears - here, here and here
3) Although my scrum team completes all our commitments just in time for the sprint, we are being questioned for our bad mid-sprint acceptance metrics. Is it completely normal in scrum teams everywhere else to meet their commitments only towards the end of their sprints?
A successful Scrum team should be completing all that they have committed to do by the end of the sprint. The burndown chart should be visible to guide progress towards this goal and certainly in the latter half of the sprint will indicate whether the sprint is likely to be a success. In successful sprints I have been involved with it is normal to make steady progress towards completing the user stories but this can not be reflected into completing half the user stories in half the time and I would counsel against a metric of this sort.