New answers tagged planning
2
There are a few different ways to approach this problem.
From a Scrum perspective, your Development Team does not have sub-teams. You may have specialists, such as people who specialize in testing, but the whole team should be involved. Rather than putting the QA specialists in a position where they must test everything at the end of the Sprint, the whole ...
4
Yes. A common rule of thumb for a two-week sprint is that most backlog items should take 2 - 3 days to complete including QA, deployment, etc. This is just wisdom for experienced teams though, not a hard-and-fast rule. It will also take time to get there. If the team is used to a backlog item taking a full 2 weeks to complete, they aren't going to jump to 2 ...
5
You should not consider development and testing as sequential activities within the sprint, or the thing you describe happens. Development and testing should happen together as a collaboration between devs and testers. It requires a change in the way you work. See more details here: What does a QA team do during the development phase of a sprint in Agile ...
5
The three main reasons why a late project ends up later if more people are added to it are - as pointed out in the Wikipedia page:
The new people need to learn, so they take time away from the existing people in the team for help. So less resources to do the work while the new people become productive and actually start contributing something.
...
0
No matter one's belief in one or another development method, or belief in this "law," what is true with every activity is that there are an unknown number of both aleatory and epistemic drivers that influence schedule outcomes. And tasks have varying degrees of resource elasticity and a single task can have varying degrees of elasticity depending ...
0
Brooks's Law perhaps needs bringing up to date. Under modern conditions team size is probably more important than the total size of a project or workstream. Lots of organisations organise their software development around small, cross-functional teams and find that multiple small teams (often fewer than 10 people) can be more productive than one large team. ...
1
Before one move into a scaled agile framework (SAFe, LeSS, or any other) everyone in the process must be 110% clear on why the movement.
The key about scaling the process is, as others already said, about doing the same process a normal team would do, but this time at another level. I've been working with Programs with 300+ engineers, so in this case a ...
0
The Innovation&Planning in SAFe is effectively an activity consisting of two parts: the first is a classical inspect & adapt exercise, much similar to a Scrum's Retrospective.
The second part is the planning exercise, when the next Program Increment (PI) is committed by all teams.
The difference with a Sprint Planning is that in Scrum it refers to ...
3
Two points I want to comment on:
When I estimate timelines
Stop estimating work for other people. Unless you are the one doing the work, you're not the one who's supposed to estimate it. The ones doing the work are the ones who estimate.
when 1 person is waiting for something, something else is being done [...] people will be underutilized for periods and ...
1
I totally agree with Bodgan's reply. It seems you are tying to micromanage a development team, so stop doing that and instead let the development team own the plan. Get the business stakeholders to nominate a product owner who can determine business priorities and let the team construct a backlog and then work through it. Are you familiar with Scrum or ...
2
I think you are approaching this from the wrong end. It seems to me that you don't need more plans, but less.
Although military in origin, the following is a well known quote in project management:
No plan survives contact with the enemy - Helmuth von Moltke the Elder
Your one plan is being changed by product and sales people. Why do you think this will be ...
0
I always thought of "points" as ... well ... "specific thumb-tacks on the project planning board." They're things that you've got to hit – not a way of estimating how long it might take to hit them.
If you have just inherited a team that is, shall we say, "not enthused," then the first thing that I would probably do is to take ...
Top 50 recent answers are included
