Podcast #128: We chat with Kent C Dodds about why he loves React and discuss what life was like in the dark days before Git. Listen now.

Hot answers tagged

12

To your overall question, while Scrum can be applied in most projects, it is not necessarily the best approach for some projects. That said, it is well suited to complex problems that require discovery of the solution and adaptation to new information. Your project sounds like exactly the kind of project Scrum was designed to tackle. However, you raise some ...


6

Think "Release" Instead of Stories to Track Value User stories are not meant to be a measure of business value. As a rule of thumb, each Sprint should deliver a potentially-releasable increment of product, but nothing requires that each iteration deliver X amount of value. User stories just represent INVEST-sized units of work that collectively deliver the ...


5

The short answer is that there are many different cases where delivering a complete, market-ready segment of functionality is not reasonable in one sprint. So, let's start with the simple answer: each of those things you list is valuable to the customer and you could make it "potentially shippable" in the sense that it is technologically and quality-wise ...


5

Product Backlog Refinement The PO comes with more opportunities for automation. These opportunities need to be reviewed, sized and an effort estimation need to be provided, i.e. a discovery session is needed. What you're calling a "discovery session" is actually a defined event in Scrum called Product Backlog refinement. [Refinement] is an ongoing ...


5

The development team is already busy working in the current sprint One of the principles in the Scrum Guide is that a Scrum team spends time during the sprint refining their backlog of work. This can represent up to 10% of the time in the sprint. In your situation this backlog refinement would include discovery sessions, review, etc. How the refinement is ...


5

Is Scrum actually suitable for all kinds of projects? Like with many things in the software industry, Scrum is not a silver bullet. It works nicely for some types of projects, and less so for others. I've often seen the Cynefin Framework mentioned when trying to identify projects types where Scrum might be used, so maybe have a look at it and see under what ...


4

Adding a bit to Daniel's excellent answer. You say: all the work is deeply technical and has no user facing consequences But you also say: focused on improving the performance of the product as a whole I can think of two reasons why you might improve the performance of the product: To improve the user experience (quicker response times, etc.) To ...


3

TL;DR The Scrum framework can usually be adapted to any product or service that can benefit from time-boxed effort and incremental delivery. That doesn't mean it's the best fit for every project, but the original question does not describe anything that can't fit into a Scrum implementatation. Question Analysis The question, as currently constituted, ...


3

Sprints and milestones are tools you can use to break a release, like the release of a new feature, into smaller and incremental steps. Most software teams are already working with sprints, by committing to complete several tasks in the next 2 or 3 weeks. One of the advantages of working in sprints, it’s that after you decide what work goes into each sprint,...


3

TL;DR The original question was tagged Scrum, so my answer will focus on how Scrum expects routine and non-routine changes to be managed. In brief, Scrum embraces change, but encourages the Product Owner to plan refinements for future iterations whenever possible. By treating refinements as new work, the framework encourages ongoing collaboration between ...


3

Hitting the nail on the head One thing I'm worried about is that team can easily game this by simply estimating higher. So instead of task taking 2, they would give it 3. Creating an illusion of improving velocity. This is a spot on recognition of the flaws of using velocity as a metric. Though also note that it's not always an intentional gaming of the ...


2

- Agile - In the Agile methodology, the role of technical lead is viable. But it’s important to understand if your team really needs this technical lead. If the team is young, probably they need a leader who can coordinate the work process, while also offering some insight. - Scrum - In Scrum, there are only three roles: product owner, scrum master, and ...


2

Who has authority? the designated group leader and Product Owner Here's one of your problems. As a Scrum Master, it's your responsibility to ensure that the Scrum Team (including the Product Owner (PO)) understands and follows the Scrum process. But the PO is your 'designated group leader'. Your boss. You need to clarify expectations from the management ...


2

he thinks the idea of a time-boxed sprint would produce additional stress in the beginning. I disagree with this assessment. The time boxed sprint is not intended to create a stressful deadline. Instead it is a natural break point that allows the team to get feedback and to inspect & adapt. A Scrum team that is a mixture of experienced engineers and ...


2

You might be looking for a Project Charter. This kind of documents varies a lot from project to project. With regards to tools and techniques, I share a part of the linked article. The Agile community has appropriated a number of different techniques or notations that have proven useful to capture high-level project information. For instance the “...


2

The simplest way to answer this question is to validate your approach against the Agile values. Responding to change over following a plan Does your approach allow you to respond quickly and with minimal cost to change? The change may be to the requirements, may be a result of technical uncertainty, or may be due to other factors. Will the milestones and ...


2

INVEST is a guideline and not a rulebook. As Scrum teams we endeavour to make as many of our stories as possible follow the advice from the INVEST mnemonic. You have wrapped some setup technical tasks into the first story, but there may well be nothing stopping you from moving them to another story. Say, for example, in the first sprint planning meeting ...


2

I would go with the approach - that has been highly appreciated by our professors, of having a simple user story which is split into multiple task. For example take a user login use case. User story : As a user I would like to login into my account.(This gives really high level view of a user story) Splitting it into multiple dependent tasks like: 1) Set-up ...


2

Tying into Daniel's answer, several Agile methods allow for aggregating stories into a larger story some call an "epic" that describes a larger deliverable like a feature. Each sprint does deliver a "potentially releasable" outcome--a variant on Daniel's phrase--like the "account section" you describe. And there often is value in showing that to the customer ...


2

Short answer is: yes. Backlogs are assumed to be emergent and are expected to change and be re-prioritized often.


1

We allocate 10% as a buffer time to accommodate any urgent requests or change requests that come after the start of the sprint. Obviously it would mean re estimation and realignment of priorities. Anything more than 10% we move out other tasks with similar estimates. I know it defeats the purpose of having the sprint if you resuffle the tasks midway, but ...


1

Obviously all of the methods we now call "Agile" were developed from scratch by the team(s) involved, so of course your team can do so! The key phrase, though, is your team. This is what is meant by "self-organizing teams" in one of the Manifesto principles. Gather everyone in a room, walk through the Agile Manifesto, and facilitate creation of the team ...


1

We conduct risk assessments during our projects. The resulting risk register enables us to share evaluations of our improvement and tells our team's story of changing and adapting.


1

For the sake of argument, ignore for one second the two entry level developers. You now have a team of just the two experienced engineers. Do you see any issues in implementing Scrum now? Probably not. You will develop in sprints, you will have sprint planning, you will do refinement, you will have retrospectives and reviews, build and deploy product ...


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