Hot answers tagged

11

I think the timing is important. During the daily scrum, he needs to focus on the "what". During the rest of the day, if he feels his experience (to juniors) is valuable, then there's no reason to stop him from dispensing valuable advice. But he cannot pollute the daily. Once he has to "walk around" to dispense his advise individually, he ...


5

With a team of four working on several different products you could consider using a Kanban-based approach instead of Scrum. Scrum works best if you have a cross-functional team with a quantity of work for a single product that makes it necessary to plan a co-ordinated sprint a week or two in advance. With your team however, prioritisation is presumably much ...


4

One user story will not give you a releasable product that represents some value to an end user This clause is added to get over the mindset of previous Waterfall practices. Doing analysis alone or doing design alone is not a valid user story. The story must result in some shippable code, which is what represents value to the user. can be delivered during ...


4

This is a problem with a simple solution which unfortunately is hard to implement. It's simple because the PO just needs to change his style from hand holding or making decisions for the team, or being prescriptive, to someone that acts more like a coach and mostly focuses on asks "the right questions" so that people figure out things by themselves....


4

TL;DR: No. Onboarding is a waste. Time and effort invested "Onboarding" is neither a functional or a non-functional requirement. In our project, we had failed to find how to address such situations within normal agile frameworks, and even on the agile manifesto itself. We went deeper and found a potential answer for such situations in agile's ...


3

Non-functional requirements aren't an Agile concept - they very much pre-date agility. Non-functional requirements are about any of the criteria that don't relate to specific behaviors of the system under design. I don't think that an onboarding flow would be a non-functional requirement, but the attributes including usability, supportability, and ...


2

You might consider using a technique like story mapping. It would also be worth having a conversation with the team about how they define value. With a clearer idea of that you will be better placed to prioritise the backlog.


2

I've never used Primavera, but it appears to be similar to Microsoft Project in that it is geared toward more traditional project management approaches, rather than agile and adaptive techniques. Traditional project management techniques may be fine for projects that have fixed constraints, clear cause-and-effect relationships between changes, and have low ...


2

Some examples of "sprint 1" stories for an e-commerce site: As a new customer I want the ability to sign-up for an account so that I can purchase As a potential customer I want to browse a catalogue of products Some examples for an HR application: As an HR user I want the ability to login As an HR user I want to retrieve an employee's details by ...


2

Don't get hung up on writing the perfect user story. Instead, if this is a new product that you are building from scratch, focus instead on: defining a big picture of what the product should do; split that vision into pieces, actions, and actors (you can use a technique called User Story Mapping for that, and create epics and user stories); place these ...


2

I would recommend getting the team together to discuss roles and responsibilities. They might list the pros and cons of having somebody in the Product Owner role who has a technical input to the work and also has authority over team members. Ideally, try and think of a way to track if the behaviour is problematic or beneficial. Perhaps a frequent check-up in ...


1

The problem you are encountering is that you are starting with a solution in mind. Then you are breaking down that solution into its pieces. The problem you are raising is not really one with user stories. It is: how do you solve a piece of a user need quickly so you can learn more about that need. Last week, I finished a market poll app in 5 hours. I didn't ...


1

Part of the problem is defining what "delivered" means. Does it mean integrated and demonstrated? Does it mean deployed? Does it mean that a feature flag has been enabled? Depending on the context the team is working in, it could mean any of these. The definition could also shift over time as the team refines its capability to design, develop, test,...


1

I think that it's also fair to say that – "sometimes user stories (and scrum in general) live up to those ideals, and sometimes they just don't." The concept of a "user story" is really just a guide to help you break down the work into small units, and to tie those units very closely to things that the end-user will actually observe. ...


1

Onboarding is an opportunity, when done right. It's all about the goals, if the only goal of the onboarding is to have another productive member of the team, all the onboarding tasks will be a dreading wasteful time. On the other hand, onboarding a new team member creates the opportunity to distribute knowledge, test current team's assumptions and ways of ...


1

I was in a similar position and while being an Agile evangelist, I didn't see any way out in the given situation. So I'll list the issues you have to solve in order to enable your PO to stop with it. You are missing a technical lead While the PO's behavior is making it harder to take technical ownership, he isn't involved full-time in your technical solution....


1

One thing you might do is get the team members to refine the backlog on their own in advance of sprint planning. They can add sub-tasks and estimate before the meeting. This is obviously not something you would want from a team collaborating on the same bit of work, but in your circumstances it might make sense. Even doing this, I would still encourage the ...


1

The fact that you say this person "opted in" to the PO role seems like it may be part of the problem. Usually POs do not choose themselves. A PO is usually expected to be a business manager, not a developer or IT management professional. A PO is someone who has responsibility for some business area or product, can make and implement decisions about ...


1

You can introduce the practice (agreement) that the junior devs go to their more experienced colleagues in the team first. Either do this reactively (the juniors have questions) or proactively (a senior sits with a junior beforehand/at appointed moments).


1

TL;DR: If it happens within a Sprint (as in your case), move the Story back to To-Do. If that happens after Sprint end, a new Story is needed. Exploring the situation in details: Story was completed as written and scheduled for the next release. A Story is completed when the definition of done is completed. Thus, if by the time the story was completed the ...


1

How can we know what profits and losses are associated with this feature? How do we know how much this feature contributes to the revenue of the whole product? This can be a challenge, but it is possible. One approach I have seen taken is to do A-B testing with feature changes. The idea being to see what the impact on a business metric is of a feature ...


1

Yes. Car and airplane manufacturers do it all the time. That's how they know when to modify or sunset a product's configuration or the entire line.


1

This is fuzzy because any argument you could make about a particular feature you could make about a whole product. With rare exceptions, Profit and Loss for one product is at least influenced by the success or failure of other products and the company as a whole. Working with correlation is a large part of understanding P&L. The best way I could ...


1

I don't have experience of any situation where you could evaluate P&L on a feature-by-feature basis. I expect it depends on the nature of the product and features but if there are costs that are product-wide it seems unlikely that you could calculate a true P&L in the accounting sense for a given feature. ROI for creating or marketing a new feature ...


1

A Sprint is never completed ahead of time. A Sprint is a timebox - it has a fixed start and a fixed end. In terms of events, the Sprint Planning is the first event and the Sprint Retrospective is the last. When it comes to finishing early, there are two possibilities. One possibility is that the team has met its Sprint Goal prior to the end of the timebox. ...


1

Try to identify the cause of the problem first. I can suggest some possible causes: Sprints are too long. Five to ten working days is a good length for a sprint. The problem with sprints of longer duration is that estimation tends to be harder, the team is more likely to overcommit, do too much context switching and then hit unforeseen problems. Unexpected ...


1

Suppose the development team are developing a product for themselves. The PO could easily be in the team. That might not fit the precise definition of Scrum team, but then Agile doesn't say you have to use Scrum. Self-organising teams - so organise in whatever way works.


1

Apart from ashes999 great answer there is one more notable mention of how to introduce Agile into non-IT organization or team. I really like the part about not going with all the buzzwords and working mainly through Agile values perspective. There is a 5 step method according to this post: https://teamhood.com/agile/agile-for-non-it/ Educate people about ...


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