Is 'mid-sprint' acceptance a valid concept in Agile/SCRUM? [closed]
https://stackoverflow.com//questions/9638514
-
10-12-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
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.
Solution
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.
OTHER TIPS
Have you tried to limit the amount of work you have in progress. If you get all the team to focus on a couple of stories and not move on until those stories are finished you should see your burndown become a lot more linear.
It might also be worth looking at the size of the stories. I personally don't like to see a story that takes longer than a couple of days to complete start to finish.
It is not a Scrum practice. It could be interpreted as a metric, but a bad one. Regarding your doubts, you're right.
Scrum has a perfect tool to follow the progression - The burn-down chart. No need to add any arbitrary milestone.
It seems your management doesn't understand the basic concept of a sprint, they should get some counselling or follow a basic training. If it is then still important to your management what's done within a week, try suggest to cut the sprint length into half instead.
1) Is mid-sprint acceptance a valid Agile/SCRUM practice? Is it being used anywhere else?
Yes, it is.
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?
If you break the tasks into really small ones you can achieve a good metric of work evolution. Therefore, design tasks to be complete in one work day and you can achieve a good burndown metric use. If you have long unpredictable-length tasks the burndown metric is irrelevant, as you said.
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?
The problem is not the team, but the tasks design. The issue regards the task granularity. Your team can get the job done in the sprint time metric, but now you need to refine the tasks to 50% of them be completed at the mid-sprint time metric. Break the tasks into smaller tasks and you can achieve the desired (linear) burndown chart.
It's non-standard terminology, but there is something to what your manager is saying.
A burndown chart that is end-heavy (that is, stays high for a large portion of the chart, then tails off suddenly at the end) is indicative of a practice where tasks are coarse-grained -- that is, a task will likely take an entire sprint to complete -- and accomplished by individual developers. With this pattern, all tasks remain incomplete until just before the end of the sprint.
That's really not the way it's supposed to work: if the backlog is in priority order, then why are issues that don't have the highest priority being worked on? In addition, this sets the "bus number" for each task very low, which can significantly increase the risk of tasks remaining incomplete by the end of the sprint.
To fix this, tasks should be broken down into much smaller chunks. If you're doing planning poker, and a task is estimated at 8 points or more, then it is likely that the task is underspecified. It must be broken down. Try and keep it to 2s and 3s (or smaller!) if possible. In this way, you can have several developers working independently on the same overall goal, and your burndown chart should begin to look smoother, and less risky, even as the same work is getting done.
Mid Sprint acceptance is not a agile practice or it doesn't work in reality. If you have correct estimation for each user story and task (e.g in Rally) then burndown chart clearly shows whether the sprint work is in alignment with the plan and can be completed in time or not. Acceptance is done only at the end of Development & Testing of user story not tasks.
