Skip to main content

What do you mean by "hard user stories"? complexBigger or largemore complex than usual?

We have here tow Backlog,two Backlogs: the first is PBIs, while the second is Sprint Backlog Item, initiallyItems. Initially PBIs should arranged and ordered according to client business, priority. I think here, you have to commitmentcommit to the end-user priorities as described in PBIs where each PBI should be user feature,feature; this feature may be user story or epic.

Before you shift some items from PBIs into Sprint Backlog Items, you have to analysisanalyse and understand each PBI, here. Here you can do accurate estimation of how muchhard this item is hard and how much time it needneeds to be DONE.

It may be a hard task to map each user feature to an item in PBIs, but as much as you understand these featurefeatures you will be able to determine the items that need to shifted from PBIs into Sprint Backlog Items and this also depends on the sprint length.

There is no rule on how you start to implement the Sprint Backlog Items, any way. Anyway you must finish your sprint with DONE items, you. You and your team select the order according to more things like implementation logic.

Look at the sprint as a single milestone, and breakebreak it down into related tasks with your team. End-user doesn't care either withabout the amount of story hardness, nor with your efforts, you can think of things by other way.

Try to not measure the item by hard or easy, you. You have to look at the sprint at onceas a whole, thisbecause the sprint contains items, which may be hard maybe easy or hard but they must still fit inside one sprint, and this dependdepends on accurate planning and estimation.

What do you mean by "hard user stories"? complex or large than usual?

We have here tow Backlog, the first is PBIs, while the second is Sprint Backlog Item, initially PBIs should arranged and ordered according to client business, I think here, you have to commitment the end-user priorities as described in PBIs where each PBI should be user feature, this feature may be user story or epic.

Before you shift some items from PBIs into Sprint Backlog Items you have to analysis and understand each PBI, here you can do accurate estimation of how much this item is hard and how much time it need to be DONE.

It may be hard task to map each user feature to an item in PBIs, but as much as you understand these feature you will be able to determine the items that need to shifted from PBIs into Sprint Backlog Items and this also depends on the sprint length.

There is no rule on how you start implement the Sprint Backlog Items, any way you must finish your sprint with DONE items, you and your team select the order according to more things like implementation logic.

Look at the sprint as a single milestone, and breake it down into related tasks with your team. End-user doesn't care either with the amount of story hardness, nor with your efforts, you can think of things by other way.

Try to not measure the item by hard or easy, you have to look at the sprint at once, this sprint contains items, may be hard maybe easy but they still inside one sprint, and this depend on accurate planning and estimation

What do you mean by "hard user stories"? Bigger or more complex than usual?

We have here two Backlogs: the first is PBIs, while the second is Sprint Backlog Items. Initially PBIs should arranged and ordered according to business priority. I think here, you have to commit to the end-user priorities as described in PBIs where each PBI should be user feature; this feature may be user story or epic.

Before you shift some items from PBIs into Sprint Backlog Items, you have to analyse and understand each PBI. Here you can do accurate estimation of how hard this item is and how much time it needs to be DONE.

It may be a hard task to map each user feature to an item in PBIs, but as you understand these features you will be able to determine the items that need to shifted from PBIs into Sprint Backlog Items and this also depends on the sprint length.

There is no rule on how you start to implement the Sprint Backlog Items. Anyway you must finish your sprint with DONE items. You and your team select the order according to more things like implementation logic.

Look at the sprint as a single milestone, and break it down into related tasks with your team. End-user doesn't care about the amount of story hardness, nor with your efforts, you can think of things by other way.

Try to not measure the item by hard or easy. You have to look at the sprint as a whole, because the sprint contains items which may be easy or hard but they must still fit inside one sprint, and this depends on accurate planning and estimation.

Source Link
Majd Kassem
  • 187
  • 1
  • 12

What do you mean by "hard user stories"? complex or large than usual?

We have here tow Backlog, the first is PBIs, while the second is Sprint Backlog Item, initially PBIs should arranged and ordered according to client business, I think here, you have to commitment the end-user priorities as described in PBIs where each PBI should be user feature, this feature may be user story or epic.

Before you shift some items from PBIs into Sprint Backlog Items you have to analysis and understand each PBI, here you can do accurate estimation of how much this item is hard and how much time it need to be DONE.

It may be hard task to map each user feature to an item in PBIs, but as much as you understand these feature you will be able to determine the items that need to shifted from PBIs into Sprint Backlog Items and this also depends on the sprint length.

There is no rule on how you start implement the Sprint Backlog Items, any way you must finish your sprint with DONE items, you and your team select the order according to more things like implementation logic.

Look at the sprint as a single milestone, and breake it down into related tasks with your team. End-user doesn't care either with the amount of story hardness, nor with your efforts, you can think of things by other way.

Try to not measure the item by hard or easy, you have to look at the sprint at once, this sprint contains items, may be hard maybe easy but they still inside one sprint, and this depend on accurate planning and estimation