Satyaprakash Joshii

Junilu Lacar says

The main difference here is that we don't go around the circle and let each person talk. The focus is not so much on each person but on each card that's on the board.

That is a good point to understand.Thank you.



Junilu Lacar says

An Agile team doesn't form around a project, then disbands when the project is done.

If not this than what is the other way suggested?


Junilu Lacar says

Again, people are not plug-and-play cogs in a machine that you can easily switch out. Each person is unique and brings their own perspective, skillset, and experience to the table.

Agreed. How does one bring these out( own perspective, skillset, and experience) during the daily meeting? In terms of DONE/Doing/TODO and any inputs if anyone has ?


Jeanne Boyarsky says

The math is that we average how many story points we got done per hour over the last three sprints and use that as a multiplier by the number of hours available.

While the team member working on a task will estimate whether the task is easy/medium/complex, how are the story points mapped to the number of hours.  
Also, how is it done for the first sprint where there is no historical data?



Junilu Lacar says

The team gathers around the board (a physical board is still the best). Starting from the right side, we work our way to the left, from DONE, DOING, to TODO.

I think apart from these there is one more thing. In case some user story planned for the sprint is not on track to get completed in the sprint, that also has to be brought out in the discussion as a risk.



Junilu Lacar says

Again, it is the TEAM that estimates the work they are taking on, not just the team/tech lead.

I did not say this for the Sprint , I said for the initial rough estimate of the project duration (e.g 4 months). Here all members may have different opinion (5 months,3 months) but someone is required to have a final say and send it as 4 months.


Jeanne Boyarsky says

My team has a spreadsheet where we enter vacation/training and such. We discount for a 10% "employee tax" (all hands meetings, timesheets, etc)

Availaility for 40-(4% of 40) hours in the week. I think that it means out of 40 hours the team members would be 36 hours productive which comes to 36/5 around 7 hours

a day.Since you talked about further discount then I think it can be around 6 productive hours a day.


Junilu Lacar says

"The code is given to QA atleast few days before end of sprint." This is waterfall, not Agile. QA is involved early. QA helps write tests up front, to guide development and design

I meant that QA will straight way start writing the test cases based on the user story but running those test cases will happen once that user story is completed.


Junilu Lacar says  

Sprint 0 and a sprint for deployment, as I said before, are carryovers from teams that cling to traditional waterfall practice.

In my company we have a practice of sprint 0, so was never having an idea that it is a waterfall practice instead of agile. Some tasks like installation, setup , getting access etc are done in Sprint 0. So when would these be done in agile if there is no sprint0?




Junilu Lacar says

3. "The team gives demo to the customer on the last day of the sprint." Sure, they can do that but they should also be engaging with the customer as they incrementally

build and design. The sprint demo should not be the first time the customer sees the software. Ideally, you have a customer or customer representative on site and

always available to give feedback and comments throughout the sprint.

Agreed.

I think below is one sample sequence of flow of events during agile project:

1. Sales team tells Delivery manager regarding a new project.
2. The delivery manager decides which resource are available to handle this project (which project manager, developers, QA). Say let us assume he creates a team of 7 members out of which 4 are developers 1 QA, 1 team leader, 1 project manager.
3. He asks the project manager about a rough estimate for the project.
4. The project manager discusses with the team leader and asks him to give a rough estimate. The team leader says he will analyze and get back to him on this later.
5. The team leader say feels this work can be done by an average member of development team in 400 hours.
6. He knows that since developers will be only say 6 hours productive in the day instead of 8 hours it will take 400/6=66.67 days for 1 developer.
7. He knows that since there are not 1 but 3 developers so it will be approximately 66.67/3 = 22.23 days to do this.  
8. He knows that he has to add buffer, so he adds some buffer say making it 22+8= 30 days.
9. He sends this rough estimate to the PM.
10. Say the sprints are to be of 10 day each, the PM and Delivery manager plan this accross 3 sprints.
11. They add a sprint 0 and a sprint for production deployment (although the code should be deployment ready at the end of previous sprint itself).
The sprints planned are : Sprint 0, Sprint 1, Sprint 2, Sprint 3, Sprint 4 (production deployment).
12. Suppose this way the work was to be finished by 15th Jan,  they put some more buffer and add one more sprint and communicate to the client that it can be done by 31st Jan.
13. The project manager forms a team from all the team members given to him.
14. During the sprint 0 the data model gets ready and any initial code setup. During Sprint 0, the project manager adds user stories to the sprint for future sprints.
15. Team starts working from Sprint 1 onwards and daily standup meetings are conducted where each resource tells what he did today, what he will do tomorrow and any roadblocks.
16. During the first day of every sprint, the scrum master (who may be a non technical person) plans the Sprint user stories the team can take for the current sprint. This may be based on the priority items of the customer.
17. The team leader coordinates with the team , helps them resolve any issues which they encounter and reviews their code.
18. The code is given to QA atleast few days before end of sprint.
19. The QA creates list of bugs some of which may be taken up in current or next sprint.
20. The team gives demo to the customer on say the last day of the sprint and before the start of new sprint project manager plans for the next sprint.
21. In the next sprint the team takes up new user stories in the similiar way. They also take anything pending from previous sprint for some reason and also any pending bugs.
22. Client may add new features to be included. Also the sprints may not go as per plan. Due to such reasons it may take additional number of sprints to complete.
23. Finally the code is deployed to production.
24. Kudos email is sent from the delivery manager saying that client is happy with their work and thanking the team.
25  Developers are released now for different project. One or two may be kept for any pending bug fixing.

Junilu Lacar wrote:This is really a big topic that gets you into things like value streams, bringing the work to teams, agile budgeting and finance (fund teams and value streams, not projects) and a whole slew of other aspects. Time boxes, small batch sizes, planning and replanning around evolving forecasts, these are all just a small part of a large complex picture.

Yes and I know it is the work of higher management but by getting a rough idea about how it happens I feel more confident. When things happen around us and we have no idea of how it happens, it appears like some rocket science. but when one has a rough idea of how things take place in an IT organization, one feels nothing is rocket science and feels more confident.

Junilu Lacar wrote: If you want to avoid that then it's better to be honest with yourselves and say up front "we think we can get all this done based on what we know now but that could change as we learn more. Make your plans accordingly."

Yes that is something every developer must learn some day in his career.

Junilu Lacar wrote:Well you can set an arbitrary time box and plan to deliver whatever work you get done within that time. It's fine to have an initial estimate using the technique you gave but you should also plan to adapt your plans based on what actually happens as you complete each sprint.

That's why the preferred term now is "forecast" because it's really a lot like how meteorologists try to give people an idea of what's going to happen. Forecasts are much more reliable as you get closer to the actual date. If you have a 30-day forecast, what you think might happen 30 days out might be very different from when you get to 10 days out or 3 days out.

Perfect advice.

Junilu Lacar wrote:Regarding the original question, let's be honest: unless the work is more or less something you've done many times before and have a good sense of what it takes to complete or the variability is very low, it's disingenuous to say "We have this batch of work and we think it will take 400 hours to complete it." Statistically, you've probably underestimated that work by as much as 100%, maybe even more. It's the cone of uncertainty.

If you want to be truly honest and transparent, you might take a sampling of the work to tackle at first, get it done, then extrapolate from your experience what it might take you to complete the rest of the work. As you work on each small batch of work, you'll get a better sense of what's involved and will be better able to forecast what it will take to complete the remaining work. If there's a high degree of variability, then your best bet will be to break down the work into smaller chunks. Working with smaller batch sizes and working in timeboxes are two main strategies when working in an agile manner for managing complexity and being able to give better estimates.

While I totally agree to this, I just wanted to get a rough idea on how the rough estimate is derived.  It may need not be near the actual but the management must be making a plan based on it on the approximate number of sprints (which may surely vary)  but something to begin with as part of planning. There would be something like planned versus actual. Actual will always be different from planned but there must be some planned to begin with.

Junilu Lacar wrote:The teams I've had have been about 5-7 people, which includes members who focus on tests, db, etc.

While all members will contribute to the time to be taken, I think the time to be taken depends most on the developers who are doing the coding (more than the one doing QA, dB etc).

Junilu Lacar wrote:The rule of thumb is 7 plus or minus 2 for an ideal team size.

Does this count include only the developers or the sum of  developers, testers (QA), project manager and not the only ones who code.?

Satyaprakash Joshii wrote:

If the number of resources will be 5 this will done in 66.67/5= 13.34 days.

I have a doubt here. Let me take an example. If it is estimated that team with 3 developers can do the development work in say 5 sprints ,then increasing the developers to 6 may bring it down to may be 4 sprints. But where is limit. How do they decide on the number developers. I know in this way increasing to 20 developers will not make the work to be done in 1 sprint. So how do they decide on the number of developers that will work on it?

Thank you. There are differences between all roles and I will read more about that. I understood  experienced members will be having leadership not necessarily manager skills.

Junilu Lacar wrote:
Leading is different from managing. Coaching and mentoring is different from managing. A senior technical person on a good agile team is a leader/coach/mentor, not a manager.

Understood this. Are there ways to practice and develop some of these skill of leading/coach/mentor on our own without anyone asking us to be in that role and giving that chance?

Junilu Lacar wrote: I'd encourage you to understand the difference between a Project Manager and a Scrum Master

Sure. I will read that.

Junilu Lacar wrote:A good manager of an agile team spends most of their time looking outside of the team, finding opportunities and work for the team

,

Thank You.I understand that he would be spending time outside team interacting lot with the customer and also with higher management. For 'finding opportunities and work for the team' , is it not the work of sales team rather than manager?

Junilu Lacar wrote:A good manager of an agile team spends most of their time looking outside of the team, finding opportunities and work for the team

Thanks.Understood it .

Junilu Lacar wrote:

Leading is different from managing. Coaching and mentoring is different from managing. A senior technical person on a good agile team is a leader/coach/mentor, not a manager.

Thank you. that was a useful basic point for me to understand.