Hot answers tagged

54

It's not that you aren't supposed to report status in the Daily Scrum. Instead, the purpose of the Daily Scrum is to enable the Developers on a Scrum Team to understand the current state of progress toward the Sprint Goal and adjust their plan to maximize the chance of the team achieving the Sprint Goal before the end of the Sprint. What the Daily Scrum ...


34

TLDR: You don't have a Scrum Master Repeat after me: The Daily Scrum is not an update-to-management meeting! Your Scrum Master(SM) is acting not as a SM, but as a manager. The problem is, the SM is not supposed to be a manager. Take a look at the described duties of the SM. Notice the complete lack of anything along the lines of 'track the progress of the ...


23

There is a lot to unpack in your question, but from what I read I see two main issues: the old guard (as you name it) doesn't want to change their way of working. What they did might have worked before, or not, but they found themselves a certain pace of doing things and the changes you want to bring forth are not to their liking. Since you mention a new ...


14

Long-Lived Feature Branches and Infrequent Merging are Anti-Patterns Which is better large feature branches or merging frequently? Which is better small work items vs large work items? This question has both engineering answers and project management answers. In general, though, the answers will be similar for both disciplines, although perhaps for ...


11

My devs are not used to unit testing framework and are still learning This will improve over time as they gain more experience. There are only 2 of them and each with their specialty (Front-end and back-end) so they have to do both the coding and the unit testing for their side of the stories. That is absolutely normal. Who else would write tests? Even if ...


11

The SM's job is to make sure that the ceremonies happen, not to tell the developers how to conduct their meetings. Daily stand-ups are supposed to be run by and for the development team. While there are no absolute rights or wrongs in stand-ups, I do think it's a waste to use a whole-team meeting to report status. Status can be read from a Kanban board or ...


7

Slightly different statement of the above - I agree with the other answers, but will share a different perspective. If you are reporting status in a meeting of N people, then that status is of no value to N-2 people. most of the people in that meeting are being paid to stand around and act like mannequins. A close friend of mine uses his daily standup ...


5

Managers need to manage The truism of "good, fast or cheap - pick one" is always relevant. You can manage with that, so long as you know what's acceptable. If senior execs expect all three, managers MUST push back. That is literally the only reason for having middle managers. If it was as simple as just giving a task and a deadline to engineers,...


4

Is Task always decomposed from User Story? No. Tasks are often split from a user story, but that does not mean that a task can only exist as part of user stories and thus they always have a smaller size. Tasks can exist by themselves. You tagged the question Scrum. User stories are not a Scrum specific thing. Your Product Backlog isn't composed of user ...


3

Unlike the Product Backlog, which is an "ordered list of what is needed to improve the product", the Scrum Guide does not specify if the Sprint Backlog is ordered or, if it is, how it is ordered. Instead, it describes the Sprint Backlog as a "plan by and for the Developers" and a "highly visible, real-time picture of the work that ...


3

TL;DR The real problem here is that your organization is framing the cost of testing as unwanted overhead, rather than as an expected and necessary cost of doing business for product development, maintenance, and support. Focus on fixing that. Analysis and Recommendations for Reframing Would you have any tips on how to improve this process so that testing ...


3

Here are some ideas that may be applicable: Rather than offering choices, present the situation to the team and have them deduce their options. Such ownership of the problem will make it easier for people to commit to a path—even if they do not fully agree. Make sure that dissenting voices are heard and their concerns acknowledged. Partner with them to ...


2

There is no direct relationship. Contracting is a legal concern, not a project management one. From a PM perspective, the contract may inform planning and controls related to scope, change management, delivery dates, budget, and so forth, but the contracting process is generally the responsibility of a company's legal team or outside counsel, and authorized ...


2

Other answers cover why the Daily Standup shouldn't be a status report to the Scrum Master, but there's a detail missing: If you need a Daily Standup for the team to know the status, then your information radiators (specifically your board that shows in-progress issues) are either not always up to date, not trusted by all team members to always be up to date,...


2

Career-oriented advice: It just doesn't matter. I would conform to the SM's request. I would de-escalate as much as possible. I would report it only as normal job duties require, and with a goal of just being truthful, nothing more. Concentrate on getting your part of the work done. If there is a 'roadblock' to your work outside your control, notify the ...


2

Short answer: yes. Being remote and geographically separated does bring challenges, but they are no different than facilitating any other meetings or teamwork in the same circumstances. You're going to have to invest time and money into keeping people connected. You'll need to make the most of times where hours overlap. One of the counter-intuitive things ...


2

You can sense the difference by understanding the reason for the existence of the User Story. User Story represents the customer deliverable business value, and it is the basic item in the Product Backlog. The user story is written on the gathering requirement stage, and later injected into a specific sprint, after that the scrum team has to implement this ...


2

What are the rules on working on Sprint Story PBIs in order There are none. All the things you mention are sensible reasons why you might not go in strict priority order. However, you may want to discuss some of these reasons in your retrospectives. Is it possible that by changing the approach the team takes you might be able to make these exceptions less ...


2

We eat a piece of cake vertically, not horizontally, a user story is like a bite of cake, when we eat a cake horizontally we don't feel the perfect flavor, what I mean here, that the user story represents value to the customer. Do you think that "use case diagram" is valuable to the customer or have more value from than landing page? find more ...


2

By the way you are describing this project of yours, it seems to be a "one time thing" and your advisor is suggesting an iterative and incremental approach by using Scrum, but didn't explain what Scrum is. I also have the feeling that they don't themselves know how Scrum works. I suggest you read the Scrum Guide to figure out what Scrum is all ...


2

There is no single answer to this question. The purpose of branching is to facilitate parallel development. But exactly what kind of parallel development you need to support could differ from company to company, team to team, and even project to project. It's like asking "what kind of vehicle is best?" Well, that depends on your needs. Do you need ...


2

The long-lived feature branches and the merge conflicts are both symptoms: you have a lot of people working on the same codebase, but coordination is lacking. Now there are two ways of dealing with this: take the most recent version from the main branch, make the minimal change that implements the interface you need and that doesn't break anything else, and ...


1

Step Wise (Hughes, Cotterell), in common with similar frameworks like PRINCE2, is primarily a description of planning and management activities and has relatively little to say about delivery methods. The 5th Edition of Hughes and Cotterell's book does discuss XP and other agile methods but seemingly without much consideration of how planning game, for ...


1

They mention it is good practice to work on PBI tasks first by Sprint Backlog Priority in code development. There is no sprint backlog priority. So no, this is not best practice. However, there is a sprint goal. This is the focus of the sprint. And as such, you should probably be working on a PBI that is neccessary to reach that goal. If you don't, you are ...


1

You estimate as a team and each team member estimates based on the whole piece of work, not just their involvement in it. A planning poker conversation could go something like this: Scrum Master: "Everyone estimate please. OK, we have a three 3's and an 8. Julie, as the game designer you gave it an 8, why was that?" Julie: "This story is ...


1

Remember: "user(!) stories" are exactly that ... a business/software requirement, expressed from the point-of-view of the user. "Users," however, are fully entitled to "expect a system to 'work,' without concerning themselves as to how it works." They have no idea how the systems which they use are internally architected ... ...


1

To echo what the others have hinted at: Testing is not a necessary evil. Testing is a crucial component of delivering quality (or at least working) software. Keep in mind that you only get one chance to make a first impression and delivering buggy software destroys your reputation. So, to answer your question: You need to budget in more time for testing - ...


1

Arrange a meeting with the high-ups for a MoSCoW prioritization. The bosses want you to do Agile? Well, then you're going to do Agile, and that means MoSCoW prioritization. Split the task you're doing into pieces, use Story Points to estimate the amount of effort it would take these pieces, and arrange a meeting with the bosses to prioritize those pieces ...


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