15
There is no planning or pre-planning phase in Scrum. I guess you are referring to Backlog Refinement and/or Sprint Planning (sprint planning is a relatively short time-boxed event and definitely not a phase). Backlog refinement and sprint planning are complementary activities when it comes to helping developers understand items on the backlog. Sprint ...
12
Sutherland decided to make the meeting at most 15 min long. In his own words:
[...] the meeting couldn’t last more than fifteen minutes. We wanted it to be crisp, direct, and to the point. If something required further discussion, we noted it and met further after the daily meeting. The idea was to get the most actionable and valuable information in the ...
12
in your practice, do you use the aforementioned disaggregation? Why or why not?
I encourage teams to focus on estimating consistency rather than on having a complicated estimating approach.
There are a number of reasons for this, including:
Complicated estimates encourage people to believe that their estimates are more accurate and when they prove to be ...
7
Actually "story points" is exactly for not doing what you are trying to do :) The idea behind it is this;
Estimations aren't accurate. Here's an article of mine about this.
Trying to estimate takes a lot of effort.
There's a misunderstanding that, every story point should match with an effort-based metric like hours, minutes, days, etc. That's ...
6
Here's a more psychology-focused answer.
Agile decreases certainty to increase delivery speed of features. This trade-off means that you will never be 100% certain about what is required to develop a specific feature. (If you were 100% certain, it would be waterfall!) This necessarily means that estimates are less precise and more likely to be incorrect.
A ...
5
A resource manager as a organiser of day to day productivity has no place on an agile team. We know why they don't belong, it's in your question. They're trying to optimise things that oughtn't to be optimised. It's counterproductive.
It could be possible that this "resource manager" is more strategic role than it sounds. For instance, at a staff-...
5
This means you are facing an issue in Backlog refinement. There is another thing that you can do - a spike. Depending on how critical it is, you may assign 1-2 days at max.
Honestly, the issue that you are facing seems more technical than related to planning. If I am not wrong then you would be delivering a potential shippable increment at the end of the ...
4
I'm going to take it a step further than Hans-Martin Mosner did in his answer. Things that are outside the control of the team should not be part of the Definition of Done nor should they be on the team's board. Since the team cannot choose if and when to deploy work that meets the other criteria to production, the team should consider the work Done with a ...
4
The reasoning behind the 15 minute limit on daily scrum meetings is, as Bogdan points out, that you should never need more than that to achieve the purpose of the meeting, which is just a daily "sync" to keep everyone up to date on who is working on what and check to see if anybody needs to co-ordinate with anybody else on any of the details of ...
3
A common theme in Agile Software Development, and especially in Scrum, is the idea of a cross-functional team. There is no concept of an engineering team finishing something on Friday afternoon and then handing it off for testing later. The team, as a whole, does all of the design, development, and testing necessary to complete the work. This doesn't mean ...
3
If the role of Resource Manager in your organization is seen as maximizing measurable activity instead of produced value, you've got a serious problem. You're going to create more waste by keeping people busy on things that can't contribute to value at that time.
If you look at the QA situation, the time in a sprint when final QA is being performed (and thus ...
3
There is no 'Resource Manager' role in Scrum
The question that you are quoting has the 'scrum' and 'scrum-master' tags. How do I manage development with testing and get proper reporting in JIRA?
So, I am answering this question in the context of Scrum.
Scrum has only three roles:
Product Owner
Scrum Master
Dev team
In addition, as @todd-a-jacobs has ...
3
Story Points are not based on any kind of tangible formula, and they are not the point of estimation.
During Sprint Planning, the team must agree on the work that is to be included in the Sprint Backlog. This is based on two things:
What items the Product Owner has put at the top of the Product Backlog, meaning they are the highest priority to complete; and
...
3
What you are feeling is normal whenever a new team starts off or you enter a team freshly.
The current (2020) version of the Scrum Guide does not even mention story points or effort anymore; the closest it gets to this topic is a short blurb in the Sprint Planning section:
Selecting how much can be completed within a Sprint may be
challenging. However, the ...
2
I agree with the earlier answers, but wanted to add a point from the Agile Manifesto that is also backed by research evidence: "The best architectures, requirements, and designs emerge from self-organizing teams." So the short answer to your question is, "Yes." As a coach, I suggest that your role is simply to help the team members ...
2
I noticed that I don't feel entirely comfortable giving a "story point" estimate, because it seems too speculative.
I agree with the other answers, but I thought I'd offer a slightly different take. Based on the above quote, the issue isn't story points, it is your discomfort with offering an estimate without a firm mathematical model.
But story ...
2
TL;DR
Retrospectives work in any environment in any organization. They are not an Agile practice, although Agile has embraced them whole-heartedly as a reflection of the scientific method for improvement and adaptation.
There is almost no situations in which a retrospective will not be beneficial. Seek forgiveness, not permission. Run a retro.
What is a ...
2
My naive point of view would be that since it's not your decision to deploy or not, those stories should not be in your Kanban board but in your client's board (if they have one, or in their mailbox, or on their desk). You've finished your work (presumably, with tests asserting that the client's requirements are met) and now your work is done. If you're a ...
2
I think you may be asking the wrong question.
In my experience, it doesn’t work - still, tasks cannot be fully developed and tested in one sprint.
From a scrum perspective, I'd say the key question may actually be "Why can't tasks be fully developed and tested in one sprint?"
Have you brought this question up in retrospectives? Have you tried the ...
1
Two of the key components in Scrum are the Product Increment and the Definition of Done. Every Sprint, the Scrum Team should deliver an Increment that is Done - i.e. it is a potentially shippable product that provides some kind of value to the customer. This implies that work doesn't get marked as done until it is Done-done, because a feature that is ...
1
Since the deployment is a time-based action;
Someone has to spend time on it, so it must be estimated
Someone has to do it at a time, so it must be something considered as a work in a sprint
Here's what I suggest;
Remove "Deploy to production" from your DOD
Create separate stories for the releases and relate the completed stories to that release ...
1
The stories have not met the definition of done and so should be left in the ready to deploy state.
The idea behind the concept of 'done' is that it is how the team defines the end of their work on a particular story. If it is yet to be deployed, then there is work still to be completed and potentially there may also need to be re-work if there are problems ...
1
And it's even a good idea to step back a little bit from the rigorous definitions found in the scrum bibles – which in this case (IMHO) might be a little bit too formal – and simply present it to the team in terms of "we should periodically take a look at what we're doing, and how we might be able to do it better – without pointing fingers at anyone.&...
1
If your management is truly supporting agility, then management should support retrospectives. Retrospectives are the only practice called out in the Manifesto for Agile Software Development, and they also support some of the lean principles. If you aren't doing retrospectives, I'd consider that something to "just do". If people do push back, you ...
1
Their concerns are, that during pre-planning developers do not have too much time to understand a task that have not investigated themselves, so making suggestions and point estimating is difficult.
So in fewer words, there is not enough time to understand a task and provide valuable feedback.
I am interested in the assumption that the only way to provide ...
1
Document as much detail as you need to get the work done, which should normally include sufficient documentation for future support but not necessarily to complete further stories or defect fixes.
I believe the best answer to your question is simply to stop discussing whether something is a fix or a change. That should have no bearing on the amount of effort ...
Only top voted, non community-wiki answers of a minimum length are eligible