Hot answers tagged

9

Theoretically, yes, you could use a burndown chart to estimate when all of the work in the Product Backlog would be completed. However, in practice and as you are seeing, it doesn't always work out. Using a burndown chart to estimate completion relies on a few assumptions, such as that the Product Backlog is well-understood and is generally static. However, ...


8

TL;DR Scrum is an empirical control process, and therefore "big, upfront planning" is intrinsically an anti-pattern. But Scrum certainly includes a lot of iterative and just-in-time planning, along with a predictable cadence and a set of inspect-and-adapt events when the framework is properly applied. Scrum Uses Iterative, Just-in-Time Planning ...


7

Kanban, i.e. managed flow rather than timeboxed sprints, makes a lot of sense for research and discovery work for exactly the reasons you mentioned. Perhaps you could still produce the metrics and status reporting to keep your team accountable to management but the idea is to focus on prioritisation and sustainable delivery rather than estimation and ...


6

Retrospective actions are a vital part of the Sprint work, so they should be agreed with PO and tracked as such. You mentioned you use a Kanban board. Why not tracking each action as an item in the board? You may want to have a mean to separate these items from the other Stories, but it all boils down to what works better for you. In our team, we use a ...


5

If you already have the three points you mentioned above, you don't need a burndown chart to estimate the completion date of the project. When you divide total story points by the velocity, what you get back is a number of sprints, which are time-boxed (usually) to weeks which you can then layout over a calendar and get the completion date of the project. ...


4

An option would be to use a burndown chart. You can then see where your work from the Sprint backlog falls at the middle of the sprint. Image is taken from this article. You don't really know what answer they expected. Maybe something simple, or something to tell them you know about the existence of a burndown, and maybe continue with some other questions ...


4

It is worth differentiating between what Scrum is (as defined by the Scrum Guide) and what is popularly associated with Scrum. For example, story points, stories, estimating, velocity, etc. are not a part of the Scrum Guide. The team doesn't communicate in the same way as engineers. They need a lot of time to discuss and hypothesise(i.e. its not what Scrum ...


3

Does Scrum take into account interruptions? Scrum does not. The Scrum team does. Scrum teams are self-organized and plan their own work. If part of that work consists of fixing urgent bugs from production or handling requests from other teams, then the team needs to find a way to organize around that, how exactly depends on the context: they might ...


3

TL;DR A Sprint Retrospective is part of the inspect-and-adapt process. The 2020 Scrum Guide says that "[t]he most impactful improvements are addressed as soon as possible," but doesn't prescribe how the team must implement any given adaptation. The whole Scrum Team is collectively responsible for working together to decide how to best implement ...


3

The question is fundamentally wrong. Like nvogel says, the Developers own and manage the Sprint Backlog. Bogdan's answer suggests using a burndown chart, a good tool to visualize the amount of work remaining in the Sprint Backlog. There are a few things to consider. There's no good measure of "half the work". Developers may add or remove work at ...


3

"As a front-end developer this looks quite simple, maybe just a 2 pointer." "Hmmm, the back-end is going to be tricky, more like 5 points." "Testing this won't be easy either." "OK, shall we go for 5 points then? Or maybe even 8?" "8 seems excessive given the front-end work is pretty simple. 5 seems good."


3

The power of planning poker lays in its consensus-based collaborative approach. You don't simply estimate the size of something, you have a discussion during which each member contributes to the understanding of what needs to be built. As a whole. And then together as a team also decide what size that whole is. When you have a team of full stack developers, ...


3

Does Scrum do planning at all? Of course it does. Just because you don't have a stage called "Planning" like in sequential development methodologies like Waterfall for example, doesn't mean there is no planning. Planning just happens throughout the entire life of the product. When you do backlog refinement, there is planning. When you start a ...


3

There are a couple of points to consider here: First, does the team want help following the Scrum framework. Granted, it can be confusing if they are calling you a Scrum Master and they don't want to follow Scrum, but it isn't uncommon. Scrum isn't the silver bullet. Also, many teams grow past Scrum - leaving behind by-the-book practices for refined ...


3

Although Product Backlog Refinement is the method by which the team ensures that the Product Backlog Item can be completed within one Sprint and has all of the necessary attributes (such as description, order, size, and/or value). However, since Scrum doesn't mandate the use of any particular tool, it doesn't tell you how to go about using any tool. Jira ...


2

A "story" does not necessarily correspond 1:1 with a development task. You need to determine from the story what needs to be done, and by whom, in order to complete it.


2

I'm still a bit junior on Scrum but I would like to point out something that I didn't find in the other replies. As much as the PO has the role to lead the product in terms on "what" is it we are going to do next to get the highest possible value, it is also true that the Scrum Team needs to develop in a way that they get to be as self managed as ...


2

This is a really good question. The first thing I would say is that all teams, even the highest performing ones, have room for improvement. The Scrum Master has the advantage of being able to focus on the team while the team members are focusing more on their work. This gives you a great opportunity to carefully study their ways of working and see if there ...


2

First and foremost, you can't use tools to solve this. If there is any problem here, it's a people problem and a communication problem. I say 'if' because this may be fine. Maybe it's something that really only effects them. Or maybe they are, after their 1-on-1, sharing the info with the right people. If you are seeing impacts where info isn't being shared ...


2

You have several options, if you are the Product Owner (PO) there are certain ways you can measure that. One of them is the sprint burndown which @Bodgan already referred to, that will tell you how many story points are done from the total, hence you can calculate a percentage or fraction of progress. You also have the point of view of the value tied to each ...


2

You don't. The team owns the sprint backlog and may modify it at any time. Trying to monitor or measure the sprint backlog seems to me like micro-management but in any case it may not tell you anything useful because the current sprint is a moving target. Burn-up charts can show you progress through the product backlog.


2

From Agile manifesto: Individuals and interactions over processes and tools Your objective is NOT to avoid communication. You want to promote it. People in a project must communicate in the most effective way they see fit. I believe you should shift the focus of your energy, changing the question you're looking for answers to questions such as How can we as ...


2

Two cases come to my mind Is everyone ok with you sharing the information? Does it make sense to share all information? Once you clarify that everyone is ok with sharing that information and you decide that it's a valuable information to share, great. My suggestion in how to share them would be based in a bullet from this answer Do a retrospectives on how ...


1

On top of what the previous commenter said that exactly The Scrum team does (plan time for bugfixing and tracking the regression), I would note that not all the bugs are blockers to deliver the iteration and prioritizing them is the key - actually, the issues just tell that the product is alive and it keeps going. Collaborating with the focus group from ...


1

The first question is how frequent and impactful are these interruptions. The 2020 revision of the Scrum Guide refers to the Sprint as "the heartbeat of Scrum". If your team is highly interrupt-driven and cannot regularly complete the Sprint and achieve the Sprint Goal, then perhaps Scrum is not an appropriate framework for your team. It would help ...


1

If there is a lot of 'hypothesising' and meeting without fixed time frames - it's more about that the scope of works is not clarified clearly yet. When the scope is cemented and timeline is prepared, but new requirements are coming or changing or meetings are delayed - we only proceed to work on already agreed scope, highlighting the delays for the Customer ...


1

Jira is not a communication tool, but that doesn't mean you can't add information gained elsewhere to a ticket. If something is unclear in the ticket description, by all means ask around until you understand it, and then come back and update the ticket description. If your conversation unearths missing acceptance criteria or a link that would be relevant to ...


1

Tiago's answer and Llewellyn's answer both give good perspectives on the overall approach. However, I'd take a slightly different approach. Since Jira tends to be more accessible than an individual's email inbox and private Slack channels or DMs, I tend to think of Jira as the source of truth and use integrations to allow people to push content into Jira ...


1

Of course your team can commit to a plan when doing Scrum. Nothing about Scrum stops you planning for the longer term, in fact the iterative approach arguably makes longer term planning much easier. What Scrum definitely does however, is encourage the team to focus on the current sprint's priorities and allow them to respond to events as and when the plan ...


1

Consider having a meeting, called Backlog Refinement, that you run before Sprint Planning. Both a developer and the Product Owner must attend. During the Refinement meeting, you go over the Stories and do a sanity test, ensuring they fit the INVEST method. If you don't want to have a Refinement meeting, this can be done during Sprint Planning as well. ...


Only top voted, non community-wiki answers of a minimum length are eligible