When is the best time to create story tasks?

Question

I have a team of developers who are relatively new to Agile and sprints (approx. 5 months now).

Every time I walk into their sprint planning session, I do not like what I see. It's absolute silence and we can practically hear ourselves breathing. The SM is the only person talking and tries to create tasks, one-by-one, for each story.

I try to encourage the PO and developers to ask questions, but I have developers who are very "passive" (not pro-active). No developer will voluntarily request to be assigned a task (like I use to do and have seen done by so many of my peers). They sit and almost wait to be assigned tasks (which was how it was before I introduced Agile).

Our sprint planning sessions are WAY too long (almost a full day) for a two week sprint. There is a lot of wasted time discussing things that should probably have been ironed out before the session by the PO.

My questions are as follows:

1. Other than a backlog grooming session, is there a formal meeting where the SM, PO, and I can pre-populate the tasks for each story?

   We know we will need certain tasks, such as:

   • unit tests
   • functional tests
   • load tests
   • test strategy meetings
   • design

   
   If such a meeting exists, what is it called?
   If not, would this, in any way, go against the Agile methodology?

2. How can I get developers more involved?

   I want them to be pro-active, ask questions, give opinions, to fight for tasks.
   

   What can I do for motivation?

3. Any recommendations on what the PO could do prior to a sprint planning session?

   I just want all the boilerplate work to be done before developers and others join the session. Having everyone sit through several minutes per story watching the SM create and name tasks, set the JIRA fields, etc. is entirely counter-productive.

Answer 1

From command-and-control to self-organizing

Looks like your team (and perhaps your organization) is struggling with transitioning from command-and-control style of management to agile. This article has some tips.

From my experience, here are some things that might help:

• Is the Product Owner describing the Sprint Goal at the beginning of each Sprint Planning meeting? This will help the team understand what they are expected to accomplish and why.
• The Scrum Master should not be creating tasks. This should be left to the development team. They are the ones who are going to do the work.
• How do you estimate story points? I recommend the planning poker method. The entire development team gets a chance to become familiar with the work that is coming up next.
• One way of encouraging the developers to participate is to split the Sprint Planning into two parts. In the first part of the Sprint Planning, the team can discuss the stories in the priority order, get clarifications on the requirements and acceptance criteria from the Product Owner and commit to how much work can be accomplished in the Sprint (based on story points). In the second part, the Scrum Master can step back and let the development team take the lead. The team creates tasks for each story based on how they intend accomplishing it.
• As @CodeGnome suggested, send more people to Scrum training. If you have a tight budget, get those already trained to train the others.

Answer 2

Introduction

Division of stories into smaller stories should be done by the Product Owner. Scrum Master and developers can help in that, especially during backlog refinement (grooming).

Division of stories into tasks (meaning: technical tasks) is only the responsibility of the development team – this is about HOW the stories will be implemented.

So I believe, neither Scrum Master, PO nor you (if you are not a dev) should not divide stories to (technical) tasks.

I just answered a question about „who?” and not „when?”, but that was for clarification. Now answers to your questions:

Answers

a) The answer to „When?” is, in my opinion: during sprint planning. I think, no other formal meeting is intended for that in Scrum. Also whenever someone sees that a task may be added to the story, he may add it. But formally, HOW the stories will be implemented is discussed among developers during Sprint Planning meeting.

b) Ask the Scrum Master to stop talking ;), to stop entering stuff to JIRA during the planning meeting. He should facilitate the meeting and encourage developers to do this work and not do this instead of them. Give pens and postit stickers with story names to developers and let them write on a sticker the tasks for that story. And take the keyboard from Scrum Master. He does not need it during the meeting. Give it to someone else.

Think about empowerment, about encouraging for self-organization of the dev team. They will not start to do this job if SM is doing it for them. Some „space” needs to be created. Make them feel responsible for technical solutions, for dividing stories into tasks.

c) SM should support PO before the planning in creating and splitting user stories and making them better understandable. Does he do that?

UPDATE regarding a):

The tasks like: design, tests, review should be a part of general Definition of Done of the team. I do not think it is needed to put them to the story during planning. It depends on what is the goal of adding them there - to have them visualized so that the size of the story can be estimated well or just to have a checklist if all the steps were done.

If it is needed for estimation and the team prefers to have it written down, then it is fine. If the team do wants to have those tasks in JIRA to have kind of checklist (do they want? or you want it? :)) then a developer when starting to work on a story can add those generic tasks. During planning it would be enough to mention it - that's something that SM can do: "guys remember that you need unit tests as well".

In my team tasks added to a story during planning session are more like: add a new button to screen A, create a new screen B, create a new db table, improve the SQL query. We put "unit tests" tasks usually when we know that in a specific story we expect a lot of effort in making/maintaining unit tests. Usually we do not write down "unit tests" task to a story as we all know it needs to be done.

Answer 3

This is the common problem which was faced by everyone who are new to Agile. Because Agile is more about taking ownership and resposiblity which was lacking in other methods. To answer your question..

1. Before you goto Sprint Planning Meeting, Business Analyst and Product Owner should have discussion and priortize the list of features which you have according to your business needs. Before prioritizing the Business Analyst should break down the features into small task and with PO these should be prioritized. In this way when you go for Sprint Planning Meeting you can avoid time in discussion which features to be address.

2. To bring in more involvement from your developers, you should first teach them how Agile works. Make them understand you are suppose to take ownership. It can be done in a simple way, in your initial meetings please avoid people from Management team, make your dev team feel confortable, make sure that what ever they speak its not going to communicated to Management team. May be initial days you can give them some time say them these are features according to priority go back do effort estimation and let the team know how much time you need, who works on which feature etc. This way you can make them involved.

3. As I mentioned above PO and BA should meet before planning meeting and prioritize the user stories to be taken for each Sprints.

Answer 4

Like other responses have indicated, it's really about ownership. In my experience, developers really like to solve problems - it's what brings them satisfaction in their work. Usually when I see a low level of interaction, it's because the developers feel like they're being giving a list of things to do and they're just acquiescing. That may or may not be what's happening, but I've never seen a case of low involvement where that wasn't the perception.

This is the same problem that waterfall has. Tier 1, business leadership, decides on some requirements and passes them down with Tier 2, the PMO, then they make tasks and give them to Tier 3, the developers, which make them, then we go back up the chain and hope whisper down the alley didn't happen.

The key is that all levels are engaged at the same time. The project should start with the team getting a high-level view of what they're trying to accomplish in the project, then as you approach each section, before you get into sprint planning, you vet ideas and requirements with team members (doesn't have to be all of them if you've got a big team. Your goal is to get involvement and buy-in, not kill productivity). For example, if you intend to tackle user feedback next sprint, a few days before it, have the product owner take the team to lunch and say "I need users to be able to give feedback with a single click from any page" - or whatever the high-level need is - "Like this site does - what do you guys think? How could we make X happen?" Take that conversation and iron out some basic stories to work from during sprint planning. Now you've got the idea in their heads for a few days, they've got some ideas rolling, and they come into sprint planning knowing what they'll be talking about and ready to share some solutions.

Disclaimer: I know this kinda breaks scrum because you're allowing POs and stakeholders to take the team off task. In my experience, the benefits of getting the team to buy in and own the solution far outweight the fact that you're taking them off task for a bit. That being said, it's something to be aware of and to control - if it starts getting out of hand, reel it back in.

This also can work really well if it's not common in other meetings Project kickoffs and release planning, for example, are great places to start these conversations too. Spending extra time to do discovery and brainstorming activities in broader planning sessions like release planning can really pay off throughout the project.

One last thing: don't worry too much about how long it's taking. You're right to worry that there's no involvement, but if the meetings are productive and it takes all day, then maybe that's how long it actually needs to go. When you pick arbitrary timeboxes for meetings like that, people will feel rushed and skip valuable discussions that will cause worse problems later.

Answer 5

We work basically on Agile methodology and I work for the team which is almost similar but bunch of QA not the developers. Before answering to the questions, some basics you need to know about the people whom you are working with. If you introduce anything then do not expect that you will get responses, specially when you are introducing something really new. Motivation is really important for them by a little giggling and being friendly somehow help them to open up themselves of what their interest is in which part of development as everyone cannot be expert in all the functionalities they develop. So digging in their minds at free time initially helps you to grasp their brains!

Answering to the questions which are raised by you :

1. Make sure that developers will feel comfortable to approach you whenever they need you. You can actually start with sessions as “ Interactive Sessions “ where each and every developer will be talking on the topic related to the particular project or may be something which you are introducing , and the topic will be assigned by you. This should be priorly informed to be prepared on those topics and make everyone listen to them ! Ask them to prepare 10 to 15 points on the topic given! Anyone can raise questions and ask for the doubts and that would be mandatory and in those interactive sessions everyone has to open up and speak whatever they feel like as senior members of the organisations will not be in those sessions so they have that liberty. Through these sessions they are well prepared with the project or subject of what you wan, which is coming up as well as they will have an idea of interest which they have already spoken and they tend to speak !
2. You can get the developers involved after these consecutive meeting held between you and the developers before the project is introduced. Its hard to do this initially but once you teach them how to speak, what to ask and what not to! then I am sure you are going to bang the crowd! Well, this can happen but only through the effort what you put in. As this is real scenario what I have given you as explainatory answer so I am confident you will win this !
3. I actually would refer you to go through the below link for PO could do prior to a Sprint Planning : http://www.cs.fsu.edu/~baker/swe1/restricted/notes/scrum.html#(8) Please let me know if these answers are of some help for you. Thanks !