How do you write completable "stories" when all members of a team have a specialty?

Question

From a user perspective our stories seem clear. From a engineering perspective our stories are a bit too broad and need to be broken up into sub-tasks. This is OK, but each member of the team has a specialty. They can only really deliver estimates for each specialty (eg data vs backend vs front-end). We also have a different capacity for each specialty on each team and the story points may not mean the same thing to each specialty area.

In addition, it seems that user stories, in general, don't get completed till the end of the milestone given that everyone is working on different things and it doesn't come together until the end.

So my questions are:

1. How do you define user stories that are completable by the end of sprint?
2. How does pointing work in team where everyone has a specialty? How can you in turn use this pointing with velocity in this case? Each specialty has a different capacity after all.

Answer 1

...the story points may not mean the same thing to each speciality area

When a Scrum team member estimates on a story they aren't estimating only for their contribution to the story. What they are doing is listening to the entire team and deciding on the story size based on the discussion.

For example, for a particular story the front-end development may be simple, but the back-end development hard. The back-end developers describe why it is hard to the team and as a result the whole team would estimate a bigger story size.

I have had a team member say this to a colleague in a planning meeting:

"You just said this is really tricky, but then you estimated a 3. Shouldn't we bump up our estimate if it really that difficult?"

Using this approach it is possible for teams of specialists to estimate collaboratively and consistently.

However, if you do have a team of specialists then the sprint capacity is going to have to be carefully worked out. I have seen teams like this start with story point estimates, but then do time-based estimates on technical sub-tasks. This allows them to check that one particular team member is not going to be overloaded. For example, the team may have a velocity of 30 story points, but a particular selection of stories that adds up to 30 may overload one discipline.

As for stories getting completed at the end of a sprint, that is typically a sign of large stories. Try and break them down as much as possible while still keeping some business value per story.

Answer 2

Barnaby said:

However, if you do have a team of specialists then the sprint capacity is going to have to be carefully worked out. I have seen teams like this start with story point estimates, but then do time-based estimates on technical sub-tasks.

This is our situation, and this is what we do. Part of our sprint planning involves coordinating to make sure that everyone is working the same story at roughly the same time, and that the tasks have been broken up to make sure no one is blocking anyone else. We have an approximate sense of the capacity of each specialty during the sprint, and choose stories accordingly.

We also identify system handshakes (ie, points where we can integrate individual specialist contributions) as early as possible, especially across APIs, even if that means faking out some of the innards. This helps avoid the "doesn't come together till the end" problem. (Your devs may not want to do this; mine didn't. I insisted & we all now see the value in trying to close those loops early so we can catch problems early.)

They can only really deliver estimates for each specialty (eg data vs backend vs front-end).

I would push back against this. My standard speech is "ok, but you've seen how long it took other-team to do something similar to this before, so estimate based on that." This encourages team ownership of the whole sprint, and can be useful in estimating and knowledge transfer as well, eg:

SpecialtyA Dev, estimating SpecialtyA task: I'd call that a 4. SpecialtyB Dev: Really? I had that as a 7, because it sounds like OtherThing you did that was a 7. SpecialtyA Dev: Oh, hm, you're right, I forgot about some-piece. Or: SpecialtyA Dev: Well, it is similar, but implementing OtherThing did all the hard part for the first time. Now we can just reuse some of that machinery, that's why it's a 4.

Answer 3

I really like this question because how often I have found myself dealing with teams struggling with similar problems. Your question also points to a handful of very important agile development concepts like estimating using story points, velocity and the definition of done.

I will answer as concisely as possible.

How do you define user stories that are completable by the end of sprint?

User stories are broad by design to encourage emergent design, in-person team collaboration and more importantly to eliminate waste, common in traditional project management where requirements documents are prepared and signed off before anything else is done.

So encourage your product owner to write user stories broadly as now. However, make sure you encourage product backlog refinement throughout the sprint such that before the next sprint planning meeting, the high value user stories (that the product owner hopes would get delivered during the upcoming sprint) are decomposed with enough details to meet the team's agreed Definition of Ready (DoR). Then, during the sprint planning, the whole team further decompose each of the user stories selected by the development team, who would obviously add the technical sub-tasks such as UI design, back-end design and so on.

Like DoR, the team must also agree on the Definition of Done (DoD). Stories that meet the definition of done by end of the sprint are considered "done", everything else goes back into the product backlog, and might end up getting selected again by the product owner depending on business priorities. Obviously, each story may also have an acceptance criteria that would need to be met like the DoD.

How does pointing work in team where everyone has a specialty?

Firstly, I assume by pointing you mean the "estimation" using story points. If not, please comment and I will update my answer accordingly.

So in agile, estimation is not done using man-hours or man-days as with traditional approaches. Story points are abstract, again by design. There are lots of benefits for using this type of estimation but two of the ones I like are:

1. Story points allow developers of different background (junior, senior, UI, back-end, architect, tester and so on) have a common unit of measurement, if you may.
2. Story points encourage rapid estimation, for whatever it is worth, without wasting too much time on a non-value adding activity.

So, during the sprint planning, let the team collaboratively estimate. Getting this right or wrong doesn't matter. There are many techniques to allow this, with planning poker being the most common.

How can you in turn use this pointing with velocity in this case?

Velocity is pretty straight forward to calculate. You take the sum of the completed story points in the last sprint (or average of the last few sprints) and that is that. Again, velocity is simply meant to provide an indicator to the team of how much work they can manage per sprint. If they do more, great. If they do less, let them discuss it among themselves. Nothing else.

Additional Comments

Your goal as Scrum Master should be to encourage your team to become more and more cross functional. This is exceptionally difficult but only a team with minimal specialists become truly efficient and almost without waste. You should read about ScrumFall, a common problem in Scrum/Agile teams that you should work to keep away from your team.