0

I'm trying to understand the following problem: within a SAFe framework a development team adds user stories after commitment, even though that commitment has not been met. The justification is that if these new user stories are not completed, the larger epics/features will be endangered.

As a side note, this team spends an excessive amount of time planning during Iteration Planning.

My question is: Should these new user stories be counted as tasks?

My confusion is around the principle of "just enough to start" during iteration planning. As in each story should have just enough information for team members to start working on them. If during the course of the collaboration, new dependencies or work is uncovered, does that constitute a new user story?

My thought is that these should be listed as tasks, and if there is ambiguity that should be factored in the estimating.

Any thoughts, insights, or feedback are welcome.

  • 1
    "if these new user stories are not completed, the larger epics/features will be endangered" -- Can you elaborate? I'm not intimately familiar with SAFe, but isn't an iteration commitment usually to delivery a set of stories, not an epic or feature, meaning an epic of feature is delivered across several iterations? Unless it's discovered that these need to be done before a planned story, I don't understand the problem. – Thomas Owens Aug 9 '17 at 18:10
  • And also, if you are discovering work at a user story level, that seems like insufficient time has been dedicated to backlog refinement. – Thomas Owens Aug 9 '17 at 18:11
  • @ThomasOwens Thank you for replying! Pertaining to your first comment: for each iteration/sprint a set of stories that the team committed to is suppose to be delivered. However, we have six iterations per increment, and each increment has features that need to be delivered. (Agile at a program level) So these if the new user stories are not completed, the larger increment feature (forecast to be completed in a future iteration) will be at danger. Does that help? – Joshua Aug 9 '17 at 18:43
  • @ThomasOwens Pertaining to your second point: Can you elaborate on this? As the team spends a lot of time in the weeds of each story, and the coaching is for them to just discuss each story enough to start working on it. – Joshua Aug 9 '17 at 18:44
  • 1
    I think your terminology is confusing. Every iteration should produce a potentially deliverable increment. You may actually to only deliver the increment every 6 iterations (and there are a number of good reasons to not actually deploy or release your software at the end of every iteration). The fact that you are discovering user stories and not just tasks is troubling. – Thomas Owens Aug 9 '17 at 19:58
2

Your question is actually quite broad and touches upon a number is issues but the good thing is its all related to backlog items in one way or another.

I'm trying to understand the following problem: within a SAFe framework a development team adds user stories after commitment, even though that commitment has not been met. The justification is that if these new user stories are not completed, the larger epics/features will be endangered.

Regardless of Framework, user stories should always be prioritized and selected by the product person/team based on business priority. User stories are broad in nature that ideally have INVEST properties. Having said that, during the planning meeting, the development team can by all means influence the product/business person/s to select some low priority requirements for technical reasons. So the question is, why did the development team not bring up this "larger epic" related reasoning during the planning meeting?

Nevertheless, keep in mind that the development team is free to add, remove and edit their own technical tasks to meet the iteration's goal. Also, it is normal for the team to negotiate, during the iteration, with the product people to do changes to the stories. However, IMO, there is something wrong with your planning meetings if this happens often and affect more than a handful of the stories.

As a side note, this team spends an excessive amount of time planning during Iteration Planning.

You should ensure product refinement is done and experiment with bul**** buzzer or simply a timer like the one below by putting it up on the big screen: http://oss.jahed.io/agility/timer.html

My question is: Should these new user stories be counted as tasks?

User stories are different from tasks. As mentioned above, user stories are written by or with the product people. Tasks are detailed activities that must be completed to complete a particular user story. Tasks are generally written by or with the developers. They are even written in different formats and styles. You can call user stories and tasks whatever you like, as long as you understand the difference (seriously though, don't come up with any new names for backlog items).

My confusion is around the principle of "just enough to start" during iteration planning. As in each story should have just enough information for team members to start working on them. If during the course of the collaboration, new dependencies or work is uncovered, does that constitute a new user story?

Just enough or emergent work are key agile concepts that minimize wastefulness and increase a team's focus on delivering the most valuable items first. However, this does not mean the developers start without a detailed plan. Along with backlog refinement, also read about Definition of Ready (DoR). The basic idea is that the backlog items that the product person/s want done during the next iteration are detailed enough and meet the DoR agreed by the team. Having said that, keep in mind that the team will not be able to decompose every single user story during the planning meeting. They should decompose enough stories for the first few days. Rest of the user stories will be decomposed regularly as the sprint progresses. Make sure the next most valuable user stories are already decomposed and ready for implementation before the current user stories are completed. Imagine mini planning meetings taking place almost everyday depending on your iteration length.

  • thank you for your feedback and insight. You've given me a lot to think about. I agree that we need to review our DOR, and a timer will help (just implemented this yesterday). In addition, our iteration planning can definitely be improved. Do you have any suggestions on areas to examine with the team, or tools that have helped you in the past (I'm familiar A3 RCPS tools)? – Joshua Aug 11 '17 at 17:46
  • 1
    Thanks. Am glad it was helpful. For new teams I generally use the 12 agile principles as a self assessment/metrics and we as a team would see how we progress towards being 100% against those twelve principles during retrospectives. With more experienced teams, a similar self reflection is done with custom metrices. Apart from that, I use numerous games or coaching techniques to improve areas of concern. Sadly, agile is not a hard Science and a lot is learned through experience. Having good mentors and continuously reading helps. – Muhammad Aug 11 '17 at 18:52

Your Answer

By clicking "Post Your Answer", you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.