New answers tagged

0

Product Backlog Refinement is essentially owned by the Product Owner but can involve the Developers for insights and their theoretical approach to implementation. Note that you don't simulate a small sprint planning here. The Whole Team includes the Scrum Master which ensures that the process takes place and the end goal is met as expected. The idea of this ...


0

It sounds to me like your very-small team also consists of, shall we say, "subject-matter specialists." And this might in the short run simply "be the hand that you've been dealt." But I think that you want to take every opportunity to emphasize that "we are all one team," and so, to the greatest extent possible, "we all ...


0

It might help to separate backlog refinement and sprint planning. Backlog refinement might be attended only by people working on the product concerned. If developers can work on multiple products, it might help to roughly define in advance how much (e.g. 30%) time/work should be spent for one product. Talk about this problem in a Sprint Retrospective. we've ...


0

I often see teams using both a top-down and a bottom-up approach at the same time. But, then again, maybe I'm using the term "bottom-up" in a slightly different way. "User stories," to me, are top-down: "this building is going to have a magnificent stone archway over the front entrance." But someone's also at the same time ...


0

A really fun way is doing a Design Sprint. Followed by some Impact mapping and User story mapping. Depending on your product get out of the freaking building and let the developers talk to actual users. Maybe research the Shiftup program to help you facilitate continuous innovation. Bring the team together with the users and key-stakeholders, get and keep ...


0

You can't do long-time planning with Scrum either. In Scrum velocity is used to plan the next Sprint (aka yesterday's weather estimates). It's a quantity that changes with time and isn't suitable for long-time planning. Not to mention that you don't estimate stories outside of the Sprint and therefore you can't know how many Story Points the backlog contains....


1

Great question! Kanban works best when all tasks are a very similar size. Your team's velocity is simply the rate at which they complete tickets. This makes predicting effort reasonably easy. Which ticket size to use? From experience, 3-5 days works quite well. If a ticket is larger than 5 days, we split into smaller tickets. If a ticket is only 1-2 days, we ...


0

As mentioned in other answers, you can go for story mapping exercise but first you may consider aligning all stakeholders to a prioritisation framework and high level objectives/ themes/ Epics (for the product you are building). The main problem with the bottom-up approach is the divergence of ideas from different individuals which may or may not be aligned ...


0

I certainly also find "chatter" to be massively counter-productive. (Full disclosure: I have never used Facebook, Twitter, or Instagram. And, there has not been a television set in my house for more than thirty years.) Team members should always feel that they can get in contact with another member of the team when it is necessary to do so, but in ...


0

I recommend that you frankly discuss the issue with your client. While, of course, they want to see "regular progress," insistence on things like "one week, and release every Friday" are counter-productive. Yes, the team should try to "parse" its work into manageable units so that there is not an excessively-long interval ...


-2

Gotta say this, also ... "story points (SP)" cannot be relied upon to truly describe the internal complexity of any software system which has been devised to satisfy them. "Story points" are a measure of externally-visible functionality as seen from the point-of-view of a narrowly-defined set of users. The underlying software system ...


2

With Scrum you can try to plan longer releases using team velocity. If team velocity is 100 Story Points (SP)/Sprint and the Product Backlog has 1000 SP then you can say you can finish in 10 Sprints. Theoretically, yes. In the real world, though, if you can have your scope of work so well-defined, why are you using iterative and incremental methodologies? ...


2

Daniel is spot on, feel free to add story points to the process if that helps you estimate the delivery time better. But similar sized tasks and average cycle-times will probably give a similar range without the time put into estimation. I think that typically when using Kanban you would release when you see fit. So either you pick a date and release ...


6

Because Kanban is not a full framework for developing products in itself (it's a method to optimize another process), there are many things it doesn't specifically account for. However, teams often track throughput in either item count or even story points if they chose to use them. You can forecast release timelines with either item count or story points ...


0

This has to be viewed as 'Conflict Resolution'. When new developer doesn't fit with existing members, it has to be seen with respect normal cycle of forming - storming - performing, etc. Even after that cushion is given, if scrum master sees that there is some conflict, the best approach would be to discuss with all members including the new employee. And ...


1

"Removing an employee" is strictly a managerial / human-resources matter. The team should not realistically expect to be able to "vote someone off the island." Merely because they want to.


8

This is a source of disconnect between Scrum and many real-world instances. The Scrum answer would be that the Scrum Team is responsible. The Scrum Guide says that Scrum Teams are self-managing, which means that "they internally decide who does what, when, and how". However, Scrum Teams often exist in the broader context of an organization. There ...


1

This seems ideally suited to an experiment: Determine what value you are trying to get out of communicating as a team Find a way to quantify and measure it Run an experiment for a number of sprints Review if the new approach had the desired impact


4

Your problem isn't instant messaging. Instant messaging in a remote team is a substitute for talking in a local team. Trying to say that all verbal communication should adhere to maximum efficiency and never saying anything unnecessary is... rather silly. But. It's equally silly for people to be constantly pinging each other (verbally or otherwise) about the ...


2

This question isn't really about "too much instant message communication", but rather effective communication channels. A few things stand out. I'm not concerned by the fact that the team doesn't always monitor their email. Email shouldn't be used for time-sensitive communications. I think it's reasonable for most developers to check their email ...


-2

It is probably a good idea to think in terms of management difficulties present in self-management scenarios. Good management is by and large a function of maturity in the manager. The less mature the manager is, the less likely the manager will be good at his/her job. Motivating people is difficult, and active people management typically revolves around ...


1

Effectiveness of communication and volume of communication are not the same thing. It is possible to be swamped by too much communication, especially if it is of the wrong type. It is also possible to be distracted by too much communication, leading to breaks in concentration and consequent time wasted by re-doing work or correcting the errors that may creep ...


1

Instant message communication is a 'must' for a remote team Here is a chart showing the 'Richness of Communication Channel' prepared by Dr. Alistair Cockburn: The curve at the top shows communications that are interactive. Face-to-face communication at the whiteboard is the most effective. The curve below shows one-way communications. This chart is old. We ...


21

This is the sort of things people write books about, so this is just going to touch on a few things at an incredibly superficial level. Autonomy leads to motivation: Research has shown that autonomy is a key intrinsic motivator. Autonomy leads to ownership: By allowing teams to make their own decisions, they feel like the successes and failures of those ...


9

Surely they are more benefits, but two that come to mind: Motivation: Daniel Pink lists autonomy as a key component of the intrinsic motivation of people in his book Drive: The Surprising Truth About What Motivates Us. Adaptation becomes more difficult when the people involved are not empowered or self-managing. A Scrum Team is expected to adapt the moment ...


1

Both are correct. The primary people involved are the Product Owner and the Developers. The Product Owner can use the refinement to ensure that the Product Backlog Items are created and clearly communicated, including taking the Developers' input on ordering. The Developers ensure that the Product Backlog Items are sufficiently defined to ensure that they ...


0

Estimation is considered a backlog refinement activity or alternatively it can be left until Sprint Planning or not done at all (some teams prefer not to record estimates). The advantage of preparing estimates as a refinement activity throughout the sprint is that doing so can save time during sprint planning. If the required backlog items are prioritised, ...


2

Estimating the size of Product Backlog items can be considered as a Product Backlog refinement activity? If your team estimates, then yes, estimation or sizing Product Backlog Items would be a Product Backlog Refinement activity. Scrum doesn't mandate any particular attributes for Product Backlog Items nor the act of estimation. Refinement moves a Product ...


1

The refinement is an activity performed together by everyone in the team. The Product Owner is, well, the owner of the product, but they can't really build the product by themselves without the team. For the team to understand what needs to be built they need to communicate with the Product Owner (in Agile practices, product backlog items are not ...


6

First of all backlog items should not generally be "tasks" at all. Wherever possible backlog items should be deliverables, features or other outcomes. Do you have an example of a backlog item that cannot be split? Most big deliverables can be split. Consider a typical sprint consisting of 10 working days (2 weeks is probably the most common sprint ...


11

I know there is an accepted answer, but I find it to have a bit of a trap in it, so I want to provide this answer for another view. I've been practicing Scrum for about 15 years and I have yet to encounter a task that could not be usefully broken down to less than a sprint. This has been in industries ranging from construction to marketing to research on ...


3

Further complicating the real-life situation is that there can be complex dependencies among the identified tasks, reflecting the architecture of the underlying system. Scrum is, and can only be, a guide. Take it for the many very-good ideas that it contains, but don't worship it.


15

It looks like Scrum doesn't address this issue in any way? No, it doesn't. Scrum is a guide. Although it prescribes stuff, it doesn't prescribe a lot of stuff. This is one of the things that are left at the discretion of the implementer. For ex, it used to provide a sample for 3 questions to ask during the daily, but those were dropped eventually (probably ...


-1

Here is what I consider to be a good, but informal, definition of the two roles: The Product Owner represents the business [stakeholders]. The people who are signing the checks, and the business people who will use and benefit from the product. The PO role faces outward. The Scrum Master represents the team, its daily activities and internal organization....


5

This isn't a new addition to the Scrum Guide. The 2017 Scrum Guide says this: The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes: Clearly expressing Product Backlog items; Ordering the items in the Product Backlog to best achieve goals and missions; Optimizing the value of the work the ...


4

"Can" and "should" are different things. I'm curious why you immediately jumped to "others" meaning "the Scrum Master". More commonly, the Product Owner delegates to others who do not have other responsibilities within the Team. As has already been covered in another Question here, the Scrum Master and the Product ...


0

Thank you guys. These responses are definitely helping me construct a conversation with the Agile Coach (a CSP SM). In looking at the recent condensed file, he has on Scrum, the vocabulary is definitely from the 2017 Scrum Guide. I think the crux of the problem here is I completed certification classes that were based off of of the Scrum Guide 2020. Our ...


4

What is taking the place of Product Goals and Sprint Goals? There's two ways to approach this. One is to say "without product goals or sprint goals, we're not doing SCRUM." And that works. But the "its just a guideline" argument comes up. So we really should dig deeper. The other way to approach it is to ask "why does SCRUM have ...


0

Most computer applications these days have a "front end" and a corresponding "back end" that are tightly coupled. Therefore, you need to regard both sections at the same time. It helps to have developers who are experienced with both sides. The total functionality of the system also builds upon itself. There's only so much discretion ...


1

I'd suggest this: look at your project, at your company, in your situation, and think carefully: "What is it that I need to know, and for the team to know, in order for this project to be successful? And, to know when it's falling off course?" Whether you (or they) call it "scrum" or not is really not that important. The important ...


4

The Scrum Guide says this: The Scrum framework, as outlined herein, is immutable. While implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices. This makes it clear that if you do not have Sprint Goals and Product Goals, ...


5

There is a lot to unwrap here, but it seems that you are in a company that is doing Scrum just by name: you don't have Sprint Goals (the 2017 version of the Scrum Guide mentions a sprint goal 27 times, the 2020 version 19 times); you don't have a product goal (the 2017 version doesn't use the words "product goal" but the 2020 version mentions it ...


11

This is a multi-faceted question, so I'll try to provide something helpful step-by-step. First, the Scrum Guide is just a guide, but it is the definitive guide on Scrum. Furthermore, it has been built and refined on decades of experience in companies effectively delivering products iteratively and incrementally. It is not the only proven approach by any ...


4

Using the team's velocity as a guideline does not seem right because then the backend developers might end up with more work than the frontend developers or the other way around. What a lot of teams will do in this situation is to estimate in story points as a team, but then sanity check that they aren't overloading one particular specialism in the team. ...


0

I like how this scrum.org article puts it: Together. How do I create Product Goals? “In any way that works for you,” would be the consultant answer. There is no particular law or rule, but there are some things that we have seen working better than others. Set Product Goals together, leveraging the collective knowledge of the group but also as a first step ...


0

The team shouldn't have to rely on points to decide how much work they should have in the sprint. Let the team use their own judgement about what stories they can take into a sprint and then track velocity retrospectively as a measure of the team's productivity. Velocity should be for the whole team's effort rather than individuals. If the team don't feel ...


3

According to the Scrum Guide, the Product Owner is accountable for "effective Product Backlog management", and one aspect of Product Backlog management is "developing and explicitly communicating the Product Goal". Creating and developing the Product Goal are the same thing. However, the Product Owner doesn't have to do this alone. The ...


4

Individuals don't have velocity, teams have velocity. Even if you have two roles in the team (backend and frontend), with some people unable to do other people's work, it's still the team as a whole that delivers work. Can you deliver only the backend to the user, with no frontend? Or the other way? No. So the sum of all the story points delivered in a ...


Top 50 recent answers are included