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.

New answers tagged

0

The Two Core Options The Scrum Team has two basic options: The rest of the team can proceed with Sprint Planning using the current state of the Product Backlog. The Product Backlog should always be in an actionable state. While it's best if the Product Owner (PO) is present in order to help the team articulate the Sprint Goal, clarify any ambiguous items ...


2

The team goes on with the sprint planning without the PO. During Sprint Planning, the team assesses what can be accomplish during that Sprint. You select items from the top of the backlog and you work on those. Sure, the sprint goal might be a little bit fuzzy, the PO might not be there to answer questions for the best understanding of what's needed, and ...


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 ...


0

I always start these with product descriptions like this: Name & No. Purpose of the product. Components of the product. Development skills required to build and or design the product. Quality Criteria of the product. Flexibility allowed on the quality criteria. How the quality will be checked. Who is responsible for the quality checking. These can then ...


0

In my experience it is best to keep the current sprint backlog relatively static, but if the new requirement cannot wait until the next sprint, I believe the only sensible way to deal with an additional requirement is to trade it with another similar sized requirement. If you allow things to be added you run the risk of the whole process of scrums and/or ...


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 ...


0

Although Agile is setup to expect and to handle change, there isn't a great deal of detail in Agile frameworks about how to handle contract changes. The assumption is that in an Agile delivery some mechanism will be put in place to deal with significant changes (i.e. change requests). For example, some organisations will work using 'time & materials' ...


2

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


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, ...


-2

Scrum is a buzz word among managers, especially those never doing actual coding/analysis/testing. It suits some specific projects, but not all. It is not suitable for many, these dealing with highly technical topics is one of them. Scrum is actually known for accumulating technical debt (is is easy to just shuffle these 'not nice' tasks somewhere down in the ...


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 ...


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 ...


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 ...


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 ...


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 ...


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 ...


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 ...


0

Agile approach ≠ lack of documentation If you need to document really important things, such as resources, working hours, equipment required, of course, you can do it. I’d rather say, you should do it. Using the agile approach you may create only summary documents that picture the ongoing situation. An interesting fact is that in the traditional ...


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 ...


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,...


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.


0

A short answer I have found easy to implement in many different kinds of teams: Create a user story for the discovery session, and treat it like you do any other story. That is, rank it high enough in your Product Backlog to get into the sprint; estimate and task it out (if you do those things); add the developers who choose to be involved; and if that ...


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 ...


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 ...


0

document our current methodology How quickly will this become out of date? Will the document be continually updated? Will enough people read the document to ensure its value? Agile teams tend to shy away from documentation unless they are sure of their value. share our team's story of changing and adapting One of the Agile values is Individuals 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 “...


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 ...


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 ...


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 ...


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 ...


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 ...


Top 50 recent answers are included