0

I am Managing a mobile app product. it contains backend team, design team, and flutter (mobile) team. User stories are usually consisting of subtasks, that involves both, backend, design and mobile team.

My questions are,

  • How to estimate such a story, since the estimation of the mobile team, is way higher than the design team and is completely different by the dev team? which estimation will be taken into account?
  • should these subtasks be really subtasks in Jira story, or should it be just tasks that is linked to the story as its parent? the reason for this question is that, when it is subtasks, we can't separately consider it done, because we estimate the story itself, and not the subtasks, then lots of problems happen, such as: I can't know how much points each developer has, 2- If the sprint ends before we finish a whole story, its story points are not counted in the report, even if it was 90% done of it, and then the velocity and burndown charts doesn't reflect the real effort that the team can do within a sprint.

I would really appreciate some practical tips of how to manage such a situation

Improve this question

3 Answers 3

Reset to default
2

When evaluating user stories, everyone should consider the total effort required by the team to finish the narrative. As a result, the back-end developer should not only estimate the time it will take him to complete his portion, but also the time it will take him to complete the front-end, mobile, design, and all testing (and similar for the other team members). The benefit of utilizing story-points in this situation is that the values are relative to previously estimated effort, and most people can estimate if something is less/more/a lot more work than a reference narrative, even if they lack the skills to conduct the job themselves.

This allows the front-end developer to account for the work of the other disciplines when estimating the total effort required to accomplish a story. If there are major disparities in the estimations, the team should meet to examine where the differences originated from and whether everyone is on the same page.

You can undertake another round of calculations for that narrative after everyone has had a chance to indicate what factors they used to arrive at their estimate. The estimations will most likely be substantially closer together.

Improve this answer
2
  • thanks for answering Olivia, but how would the let's say, frontend guy, have any idea, how complex is a part of a story to be implemented in IOS? usually, he has zero experience with that
    – Belal Mostafa
    Commented Sep 25, 2021 at 19:52
  • 1
    After a few iterations the frontend guy should have some idea about how the iOS guys would probably estimate the story. For example, if it needs a widget that iOS doesn't have he might know that implementing that takes more effort than hacking together a similar widget with Bootstrap or whatever framework he's using. That's one area where communication within the team is important.
    – Hans-Martin Mosner
    Commented Sep 26, 2021 at 16:05
1

Do you have one team or multiple teams? Your description isn't clear on this. If you're doing Scrum, you really should be working with one team that develops a common understanding of complexity of stories.

Story point estimation is only applicable if it is done by one team in consensus. This may involve discussion and re-estimation if initial estimates by team members differ considerably.

If developers find that story subtasks place too high burden on individuals or subgroups (such as the backend devs) so that the sum of story points matches the team velocity from experience, but the sprint seems to be at risk, they should take that into account when selecting stories for inclusion in the sprint.

Improve this answer
1
  • 2
    I actually just finished the sprint planning, and to answer your question, we have only one team. and we did exactly what you said, all team agreed on the story point of a story that had both backend and mobile work. thanks for your response
    – Belal Mostafa
    Commented Sep 26, 2021 at 15:02
0

A sprint is a time-boxed event. In that event, everybody must complete some stories and provide output.

Mobile and backend developers can work in parallel for the same story, but the designs of that story must be ready before they can start. This brings us to create a separate story/task for the design. When the story/task for the design is completed in a sprint, the mobile & backend developers can start working on the main story in the next sprint.

Since you have separate stories/tasks for the design and the mobile & backend parts, they will have different story points. This solves a lot of problems of yours.

To move on cleaner, you can have two parallel sprints, by the way; a design sprint and a development sprint, for example.

Of course, the backend developers and the mobile developers ( or frontend developers ) will give different story points to the same story, but that's why we play the planning poker.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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