Get certified - Transform your world of work today

Close

Make Sure a User Story Has Enough Detail

What to do when facing a poorly written story for a legacy project

14 July 2014

Avi Gondalia
Undisclosed


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:

Available capacity: 8 (resources) * 9 (productive days) * 7 (productive daily hours) = 504 hours
Plus one additional resource (because in total we had 9 resources)

Available capacity: 1 (resource) * 4 (productive days) * 7 (productive daily hours) = 28 hours

Hence total available capacity would be 504 + 28 = 532 hours only (not 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.


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 2 (1 ratings)

Comments

Tim Baffa, CSM, 7/22/2014 11:35:35 AM
Ashvin, not sure I agree with your approach to mitigate the need for greater User Story detail.

I am a strong proponent of the team and the business discussing a user story at length to develop all of the items that would satisfy a DoR (Definition of Ready). However, I would not endorse the most-skilled team member to perform work that is outside of the accepted sprint offer by the team.

It seems that this is more of an accomodation (premature optimization) that doesn't address the underlying issue. Why are the stories built poorly? What can the team and the business do to improve the quality and thoroughness of the User Story?

On the surface, more time needs to be spent refining the stories and adding more detail and acceptance criteria. Allocating a single team member to perform this function not only creates a single point of failure, but also harms team development and their ability to grow in this practice.

You must Login or Signup to comment.


The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


 

 

Newsletter Sign-Up

Subscribe