7

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?


  1. 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?


  1. 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.

  • 1
    What is your role in this project and team? – Paweł Polaczyk Jan 30 '14 at 9:51
  • A full day of Sprint Planning for a two-week sprint is about right. Why do you think it's "WAY too long?" – Todd A. Jacobs Jan 30 '14 at 12:12
  • @CodeGnome: Scrum Guide says: "Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter." So indeed Jeach can expect it to take rather less time. However, perhaps your question "Why?" regarding his reasoning is still valid. – Paweł Polaczyk Jan 30 '14 at 12:57
  • @PawełPolaczyk "Usually" is statistically meaningless. Sizing a time-box properly depends a lot on project and feature complexity, and on the experience level of a team. Scrum is about optimizing for tight feedback loops rather than meeting speed. YMMV. – Todd A. Jacobs Jan 30 '14 at 13:40
  • Why are you in the meeting? If you aren't a developer, Scrum Master, or Product Owner, then you don't belong in Sprint Planning unless you're invited by the team to answer questions about a specific feature or user story. It rather sounds like the organization as a whole lacks adequate Scrum training, experience, or buy-in. – Todd A. Jacobs Jan 30 '14 at 14:21
4

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.
  • +1, especially for your bullet about how to split Sprint Planning. – Todd A. Jacobs Jan 30 '14 at 21:38
  • I like your term "command-and-control"! It was much worst than this.. more like dictatorship and micro-management. Developers were not allowed to think for themselves. They were told what, where, when and how. Then, not trusted so everything was revalidated by the previous manager, creating a major bottleneck in the development process. It was a lot to get away from. But I managed to do it. Now I'm stuck at trying to empower them and "self managed". Thanks for your answer. – Jeach Jan 31 '14 at 7:17
  • How many developers would you consider the maximum to be involved in a Sprint Planning? We currently have 9 developers. I was thinking of splitting them up, but I'm often reminded by people who are suppose to have Agile experience that this is anti-Agile since everyone should be involved. I'm at the point were I'm really, considering in splitting up the team in two and figure out how each team can keep updated with each other. – Jeach Jan 31 '14 at 7:24
  • 1
    Sure, I have some thoughts on that. However, let us not hijack this thread for a different topic. Please post that as a separate question. – Ashok Ramachandran Jan 31 '14 at 14:19
4

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.

  • +1. You and @ashok-ramachandran covered all the points I would have made. – Todd A. Jacobs Jan 30 '14 at 21:44
  • As per your answer in 'b', right now our SM does everything in JIRA on a large monitor. I've seen this in many places which is why I allowed it. This is good advice that I will definitely put to practice. Thanks Pawel! – Jeach Jan 31 '14 at 7:10
  • As per your answer in 'c', yes the SM does help in doing this in a meeting they call "Sprint Preparation".. which for some reason I don't like the name. I definitely want to read more on Backlog Grooming and everything that event involves. – Jeach Jan 31 '14 at 7:12
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.

  • Item #3 is incorrect. The PO should define and prioritize features on the Product Backlog. Defining the tasks needed to deliver those features within the Sprint is the development team's responsibility. – Todd A. Jacobs Jan 30 '14 at 14:16
  • I think he meant user stories. I've seen that switching of terms a lot. iArunraj, if you did in fact mean User Stories in #3, you may want to update your answer to reduce confusion. – Daniel Jan 30 '14 at 16:05
  • @CodeGnome Although you are 100% about the developers responsibility, I strongly feel that many tasks, such as Design, Write Unit Tests, Write functional test, Code Review, etc, etc are all tasks which we know for sure we'll need. So why have all the developers spend at least 10 minutes watching the SM create and populate the fields for these tasks. In our case, it is dead silent during this time and I hate it. Obviously, specific tasks should be discussed and created live by the developers. – Jeach Jan 31 '14 at 7:05
  • 1
    @Jeach: Actually, why are those tasks (design, tests, review) added to the story at all? I think, they should be part of general Definition of Done of the team, which applies to each story. If everybody knows them, no need to write them down - at least not during the sprint planning. Enough would be if SM just mentions it: "guys remember that you need unit tests as well". At least that's my feeling about it, there are no any rules regarding it, I guess. I'll update my answer to elaborate it a bit. – Paweł Polaczyk Jan 31 '14 at 9:18
  • Yes Daniel what I meant in #3 was user stories.. I have updated my answer .. Thank you.. – iArunraj Feb 3 '14 at 12:40
2

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.

0

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 !

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.