Retro feedback

The bulk of this comes down to team, and perhaps even organizational, culture. Promoting self-learning needs to be something that is supported by both the organization and the team. If self-learning is something that is desired, this can be accounted for in Sprint Planning. When you determine the team's capacity, you can allocate time for self-learning.

As a specific example of capacity planning, you have 6 people working in 2 week Sprints. Assuming a traditional 40 hour week, each person works a total of 400 hours and your team has 2400 hours. However, what if each person dedicated 36 hours per week to the Sprint, giving them half a day for self-learning? Each person would work 360 hours per Sprint and the team would have 2160 hours. If you are completing approximately 60 points per Sprint in a 2400 hour Sprint, how many points do you think you'd finish in a 2160 hour Sprint? About 54. Maybe we want to say 50 or 55 instead, just for a nice round number. If you plan for 50-55 points instead of 60, you can have more time. Of course, this is all approximations. Plus, you would also need to consider planned time off, holidays, company events, and other things, so planning on a 40 hour week is probably not a good starting point - I don't believe that any organization is 100% effective all the time. But this shows you roughly how you can approach Sprint Planning.

I do have some other concerns with what you describe - allocating work to individual developers early, having development and test efforts in the Sprint, what sounds like an isolated QA team. There may be good reasons for some of them, or they may be leftovers from a more sequential approach to development. I would definitely want to take a good, hard look at why these are the way they are and focus more on a whole team approach to delivering throughout the Sprint. But those are probably other discussions to have. You can develop better Sprint planning habits now and tackle these later on.

one of the team members came up saying that he is only busy with sprint work and not getting enough time for self-learning

How is the rest of the team looking at this? Is self learning part of your delivery plan? Is it taken into account when planning the sprint? Is it calculated when determining team capacity?

So ideally, the devs are free by the end of the 7th day of the sprint. The last 3 days they use to write the test cases for the code they have written.

??? "free" ??? Strange wording, since the entire team should be free, free to organize the way they seem fit.

If you mean free as in not code development, this is strange as well. If testing is part of the Definition of Done, one is not Done after code completion, so also not "free".

Is it too much they are investing in sprint?

An excellent question to ask the team

devs were keeping a story to themselves

Maybe this can be improved using the Inspect & Adapt feedback loop? Improve collaboration?

with the scrum meetings, or other internal meetings, and sprint work plus test cases writing is taking up their entire time

Generally speaking, I would say the work is well forecasted and planned...

In one of our retros, one of the team members came up saying that he is only busy with sprint work and not getting enough time for self-learning.

Was this captured as an improvement item in the Sprint Retrospective, and planned into the next Sprint Backlog?

Every dev doesn't get more than a 13 pointer in his bucket.

How do the team collaborate on implementing backlog items, so as to demonstrate teamwork?

Every dev doesn't get more than a 13 pointer in his bucket. 

Is there an understanding that the entire Development Team is responsible for each item forecast in the Sprint Backlog?   What is the recourse to keep work moving forward if one of the Development Team members is unavailable (i.e. - illness, personal reasons)?

We, as a team, have divided the 10 working day time into 7 days for dev effort and last 3 for the testing effort.

From your stated practice of working with very large items (one Development Team member - entire sprint), and dividing each sprint into "phases", you seem to be reinforcing silos and specialization, and practices that do not align with Scrum.   Perhaps as their Scrum Master, helping the team mature in team ownership and self-management can free up some capacity for their desired self-learning?

Hi,

Thanks for reverting.

I am not sure where I am going wrong. I keep getting this that I need to plan better. The team is full of young and new people and only to get them into a habit of staying in the timelines, we introduce the 7: 3-day approach. When it was not introduced, the devs used to go for spillover. This introduced some seriousness in them.

In India, we have a tester as part of the dev team too who is then responsible for testing the stories in a QA environment. When I said the devs get free, I meant, when they push stories to QA after doing a code review and dev testing, they then start working on the test cases and QA (tester) is then testing the stories.

The tester is very well part of the team but is responsible for the testing. His/her sign off is imp before the production release. What better sprint planning habits I can adopt?

 The majority agrees. Self-learning is not as such part of the delivery plan but the happiness quotient of the folks is also something we can't ignore. The PO I am not sure will be willing to spare a 5/8/13 pointer story for self-learning. How do i improve using the inspect and adapt loop? Can you suggest?

Can you all please all help me how to make sure that the sprint work is done, unit test coverage is done too. The dev team keep asking for a 5 or a 8 pointer story for all such things. Like they need a reserve of 8 pointer story for self learning, to write test cases, another 8 pointer. This way they are asking 16 pointer straight for non productive stories, as per PO.

It really sounds like you are trying to account for every hour of the day for every team member as an item in the Sprint Backlog.  Everyone above has pointed out in different ways why trying to plan 100% of everyone's time is a bad idea. In fact that practice lead to a number of failed waterfall projects. 

The PO I am not sure will be willing to spare a 5/8/13 pointer story for self-learning. 

What does the organizational management say about self-learning and it's importance?  If you were not doing Scrum, how would the organization address this issue?  Ask the Product Owner if they spend 100% of their time working on items for the Product Backlog? I am going to bet the answer will be no. 

Stop trying to micromanage everyone's time. Help the organization focus on the value of the work being done instead of the amount of time taken to do the work.  Let the Development Team self-organize in a manner that allows self-learning opportunities while also delivering incremental value continuously. Focus your efforts on helping the Development Team organize their work for maximum efficiency for all, not just for some.  Having a QA sitting for 7 days waiting for new work seems really inefficient.  You may have addressed the consistent carry over problem with the 7:3 day option but it isn't really fixing the problem that your developers take as long as they allowed to finish work instead of finishing work in the time it should take. In my opinion, the team is "gaming" the system. I expect that all of the developers would find it difficult to prove that they needed 7 days for everything they work on. And if they work on 3 items in a sprint, ask them if this scenario could be accomplished.

• Item 1 takes 3 days for coding.  Hand off to QA
• QA takes 1 day to test Item 1
• Item 2 takes 2 days. Hand off to QA
• QA takes 2 days to test Item 2
• Item 3 takes 2 days. Hand off to QA
• QA takes 2 days to test Item 3.

That is a total of 8 elapsed days of work.  I see 2 days available for refinement and self-learning in a 10 day Sprint. If one QA is able to test the normal work in 3 days for the entire team, it seems reasonable that the same QA can test across many days for many developers. 

Can you all please all help me how to make sure that the sprint work is done, 

@Rhea Pillai, From what I am reading and understanding, the first thing that needs to happen is better teamwork in trying to tackle the challenges that are raised while ensuring the work is being done.

The complaint that there are lots of meetings is a typical indication of the organizational culture over which Scrum is just placed. If I may ask, what are these other meetings that's consuming the time of the Dev Team. Can someone else represent the Dev Team? Perhaps the Scrum Master or the Product Owner, if they have the technical knowledge.?

The idea proposed by @Thomas Owens is a good place to start.

Try looking into TDD so that there is better collaboration between the Devs and Testers.

The tester is very well part of the team but is responsible for the testing. His/her sign off is imp before the production release. What better sprint planning habits I can adopt?

Without any further insights, my first guess would be to split up the 13-pointers into small slices, which can be delivered to QA in small iterations, making sure testing is a continuous process during the sprint, and you get some cadanse going, instead of something looking like a small waterfall, with throwing stuff over the fence

The PO I am not sure will be willing to spare a 5/8/13 pointer story for self-learning

Suggest this to the team, see if they agree

How do i improve using the inspect and adapt loop? Can you suggest?

In my opinion, it all starts with transparency. Be transparent about where problems can be found, where flow is obstructed (in process, but also in team dynamics and individual growth). Ask the tough questions, see where improvements can be found. Keep asking questions, keep being curious, keep people venting their thoughts, not only during retro, but all day every day. Have regular one-on-one talks, to kget each individual's perspective. Preferrably in a "lets get a good coffee" kinda way, instead of making it a formal meeting.

The dev team keep asking for a 5 or a 8 pointer story for all such things. Like they need a reserve of 8 pointer story for self learning, to write test cases, another 8 pointer. This way they are asking 16 pointer straight for non productive stories

Ok, first of all, points are a planning enabler. They are not credits, nor merrits, they serve the purpose of being able to plan and forecast better. So don't assign value to the points themselves, and don't treat them as an indicator of lagging or performance.

Maybe they ask for a 8-pointer, because the 13-pointers are to large and complex to oversee for them. Did you check this?

Also, I am very much triggered by you calling writing testcases "non productive". if proper testing is part of your Definition of Done, all code development is non productive without testing!!! testing is an integral part of producing increments and therefore value. There seems to be a mindset or view problem here. Producing code is not a measure of progress or performance!

Next to that, personal growth and self learning are absolutely productive activities! They don't produce code, but surely produce valuefor the team itself. And by improving, being able to produce more value in software increments. Maybe, on the long term, the hours spent here, might prove most valueable of all!

Maybe investigating these concepts and views or mindsets are a good place to implement some Inspect and Adapt ;)

Thanks for the inputs.

Micromanage is the last thing on our mind. We estimate the stories in pointers and not in days/hours. 13 pointer story cant be broken down because then the dev says it won't be testable. It's not that the devs don't deliver a 5 or an 8 pointer story before the 7 days mark. The approach was introduced only to make sure that they at least follow certain timelines. We have just set a ballpark date so that we can get them into a habit of delivering. 

If I ask them how many hours worth of work a 13 pointer story will be, that's where the micromanagement will come. They will not be comfortable giving me no. of hours because I would be then accounting a story from that standpoint. They keep saying that when we dug into the code, something else came up hence the story took time.

Besides the scrum ceremonies, the team has internal sessions to understand the story better and to discuss how it should be technically achieved or if the team members have any doubt left, that gets discussed. 

I do agree that writing test cases and self-learning is productive and should be done, but the dev team wants the no. of stories to go down in a sprint, in order to achieve that. I believe, they are only targetting for less sprint work, so that they can then do their self-learning and cover the unit test coverage. I have another team who manages their time well and does everything within the 10-day sprint including the unit testing, meetings and all.

Can I just add something that makes my developer-ey senses tickle intensely after reading this sentence:

The last 3 days they use to write the test cases for the code they have written.

This surprises me for a professional software development organization anno 2019. What about test-driven development? Did the developers come up with that schedule themselves? Because this sounds like the organization may be putting quantity above quality.

On another note...

I do agree that writing test cases and self-learning is productive and should be done, but the dev team wants the no. of stories to go down in a sprint, in order to achieve that. I believe, they are only targetting for less sprint work, so that they can then do their self-learning and cover the unit test coverage.

I'm having trouble unpacking this. First you say that writing test cases and self-learning is productive and important, but then you seem to thing that the team investing in it means they are reducing time spent on being productive and doing important things.

Besides the scrum ceremonies, the team has internal sessions to understand the story better and to discuss how it should be technically achieved or if the team members have any doubt left, that gets discussed. 

You just defined refinement in my opinion. Why not help them see that those are useless meetings and are instead part of the process that enables them to do the work. 

I do agree that writing test cases and self-learning is productive and should be done, but the dev team wants the no. of stories to go down in a sprint, in order to achieve that.

I don't see this as an unreasonable request. To me this shows that the Dev Team are invested producing quality and feel that they are being rushed and possibly sacrificing quality for time. 

I have another team who manages their time well and does everything within the 10-day sprint including the unit testing, meetings and all.

This may sound flippant but good for that team. However you should not be measuring one team based on another.  I have teams that are able to finish 10+ stories in every sprint and other teams that finish 3-5. It all depends on how the team refines stories, the area of technology that they are dealing with and the problem space in which they work.  Not all development work is equal and not all teams behave in exactly the same way. 

Based on your follow up responses, I seem to think that the Development Team is working well together. It may be that you are seeing problems that don't exist.  As with everything, don't make decisions on your own. You are part of that team so bring it up with all of your teammates to discuss and arrive at something all are willing to try. 

I do agree that writing test cases and self-learning is productive and should be done, but the dev team wants the no. of stories to go down in a sprint, in order to achieve that.

Sounds normal. And be aware, because right now it seems you have some honest communication happening, which is a good thing, but you might also have the team gamble you and system by:

1. Making sure they divide each story into finer 2 stories - sounds like a good approach, right?

2. Showing that they are now doing doing twice the number of the stories as the other team.

3. Show that they can now "safely" reduce number of stories to accommodate more self-development.

Of course, this would be just manipulation, caused by the company policy, communicated by you. That would be bad.

One more thing: I understand the solution you took with 7/3 days. However, after the code freeze on day 7, the team might already have tests done and instead try to look at some other tasks in backlog.