I have observed many times that a user story is not up to the mark, especially if the product owner is internal (for an internal project). In this sort of scenario, there is often no acceptance criteria, as the PO believes everything described in the story is in fact acceptance criteria.
The development team is then left struggling to understand what they should work on until they start the sprint. Even after starting the sprint work, the PO has continuous interaction with the ScrumMaster and the dev team and pushes extra scope. (The "trick" is what the PO initially writes is at a high level, and once the sprint has started and he or she gets clarification from the client, the PO suggests the detail for the work. In this way it is said to be "not new work.")
As a ScrumMaster, you have to take strong stand on story detailing. If the team is working on legacy code, then it is an added challenge to come up with the precise time line for the story and task, as most of the implementation will be done through digging through the code and writing only few lines of new code.
In a couple of projects I faced this situation, so we developed an approach. We had, for example, nine resource teams (one with eight years of experience and the rest with three to five years). Most of the time in India there would be only one guy with six to eight years of experience, and the rest of the team would have very little experience (Scrum suggests that every team member have the maturity to understand the work and take on the responsibility by themselves, but due to cost improvisation, often team formation has more of a pyramid structure).
We ran two-week sprints: ten working days, meaning nine productive days and half a day for review, half a day for planning. On the planning day we planned for eight resources at seven hours per day, for nine working days:
8 (resources) * 9 (productive days) * 7 (productive daily hours) = 504 hours
Plus one additional resource (because in total we had 9 resources)
1 (resource) * 4 (productive days)
* 7 (productive daily hours) = 28 hours
Hence total available capacity would be 504 + 28 = 532 hours
567, as in 9 resources for 9 days at 7 hours per day)
The question that arises is what work will be done by the resource (most senior person) who has loaded for 28 hours of work in the sprint
. The answer is that he will be working on two main tasks, as follows, which we were not tracking as a sprint task for him due to their uncertainty:
He would be totally involved in the discussion with PO to come up with the FTD (functional and technical document) for the next sprint.
He would be guiding team members on current sprint implementation issues (people will be working according to the FTD document, but any clarification about how required guidance).
So in the entire second week, the senior-most resource would be completely dedicated to the new FTD (the next sprint's FTD) and supporting resources for current FTD.
To come up with complete functional understanding, he might have one or two discussions daily with the PO to fine- tune the requirement in detail and document it. Once done with the update, he would need to send it for review to the PO, who could suggest any review comments/updates.
In parallel, the senior-most resource has to dig down into the code and come up with the class- and method-level details that need to be modified to implement the story (this will not be reviewed by anyone).
The expectation is that, starting on the second week, from Monday to Friday EOD, the FTD document is required to be ready for the PO’s sign-off. On the following Monday, it will be discussed in the planning call about the FTD, which has details from the requirement and implementation points of view.