New answers tagged

2

Effort Estimation in Agile Software Development using StoryPoints gives a good overview of the story points accuracy: The cone of uncertainty is inherent to estimation. For improving the estimation accuracy, various optimization techniques have been proposed. The Support Vector Regression (SVR) is one of these techniques that helps in getting optimal ...


1

Behaviour Driven Development (BDD) can be a neat way to reduce the overhead of requirements traceability. The approach is as follows: Requirements are generated by the stakeholders/Product Owner The 'three amigos' (representing business, development and testing) get together and create features and scenarios that correspond and flesh out the requirements ...


1

Firstly it is worth noting that the Scrum framework is designed to use iterative development and feedback to build a better product. You are unlikely to get all of the benefits of Scrum when using it on a fixed-price, fixed-scope project. As for estimating, there is nothing to stop you using the same method you would use on a traditional project. For ...


0

PBIs should not be treated as something different from epics or features. Epics, features, requirements, and tasks can all be product backlog items. In Azure Devops the hierarchy is as below: Epic |_____Feature |______Requirement |________Task Epic, being the top-level requirement. The goal is to break down anything that'...


4

Scrum isn't used to tell you when something will be delivered. That's not its purpose. Scrum is used as a framework to develop software transparently that will provide immediate value to its users and customers. It mandates a self-organized, cross-functional team that decides what it works on and when. This is at cross-purposes with your requirement to ...


1

Without external measuring devices, I can compare two cups of water and guess which one is fuller than the other. I can't tell you how much exact liquid I can fit in the cup, nor can I tell you whether putting the liquid from one cup into the other will result in overflow without trying. If both are really full I may have some ability to do so; but it ...


3

Your understanding of traceability is correct. The idea is to trace functionality from the source to the implementation and deployment in order to determine if the system implements the required functionality. Any change, no matter how big or small, needs to have a ticket in an tracker, like Jira. This is somewhat correct. Tools like Jira that have ...


2

I would like to share a few comments to add to the discussion. First, a fixed contract means that the client is buying a defined set of working hours for a set price. You will typically present a work plan to the client which will include work packages. The Work Package 1 (WP1) will start on a "Start date of WP1" and will end on WP1 + y w (where y is the ...


4

There are two parts to this answer. The first is how you estimate and the second is if the premise of your question is inherently problematic. Estimation First, the estimation. Generally speaking, there are two broad types of estimation: relative and absolute. Absolute is what we think of in traditional project management. You take a list of tasks and ...


2

To use Scrum to good effect you would want the customer to understand that the product is a collaboration to which they will contribute through continuous delivery, review and feedback and product ownership. That being so, a given target date perhaps becomes less important than achieving a sustainable pace and ongoing customer satisfaction. Once you have an ...


10

Let's be serious, people don't usually care how you do estimates. What they care about is how much it takes and/or how much it costs. Time and money. That's what they want. The estimates is just something that helps you answer those questions. It doesn't matter what you use for estimations as long as people can get back a time or money value. It can be ...


7

I know of at least two "Empirical assessment of machine learning models for agile software development effort estimation using story points". Available online at https://link.springer.com/article/10.1007/s11334-017-0288-z "Empirical Validation of Neural Network Models for Agile Software Effort Estimation based on Story Points". Available online at https://...


5

Each person in a team may have his personal understanding of the correlation between an effort and Story Points. Initially, in a new team, that may be true. That is why an estimation based on Story Points is more than each team member just giving a number and then taking the lowest/highest/average/whatever as the final estimate. When doing a Story Point ...


14

Story points are a relative measure of effort rather than an absolute one. However, each member of the team should have the same understanding of the size of a points estimate. A common understanding is achieved when the team estimates repeatedly together and when they agree common baseline stories against which to measure. This is really no different to ...


3

Mike Cohn has a great article on Story Points. Some of the highlights are Story points are a unit of measure for expressing an estimate of the overall effort that will be required to fully implement a product backlog item or any other piece of work. ... Because story points represent the effort to develop a story, a team’s estimate must ...


0

I've worked with quite a few teams and know that your experience is not uncommon. The retrospective is challenging for a number of reasons. I can list a set of common challenges I see here, but this is by no means exhaustive. If some of these don't lead you to an improvement, I'd consider consulting a local agile coach. Challenge #1 - Fixed vs Growth ...


1

Although I'm not aware of any formal research, I can recommend a few books on retrospectives and coaching that are likely to be useful - Agile Retrospectives: Making Good Teams Great by Esther Derby and Diana Larsen, Agile Coaching by Rachel Davies and Liz Sedley, and Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in ...


1

I'm not aware of any reports or research on this. But doing many retrospectives over the years I've recognized smells or antipatterns that cause retrospectives to become ineffective. A retrospective smell is a signal that something might be going wrong in your retrospective. It’s a warning that problems might happen that will impact the retrospective result....


0

As I understand scrum, yes the sprint goal can be changed, with the acceptance of the team - but it is more like restarting sprint than "while running". The advice I was given when learning scrum was: Changing the sprint goal is disruptive and cause problems, so it should be discouraged for stakeholders to request a change. Why is "top of next sprint" not ...


0

What you are doing here is not Scrum as Scrum is defined. Some of the deviations include multiple Scrum Masters and a lack of a Sprint Goal. This makes it difficult to give an answer in the context of Scrum. Now, with that out of the way, you are asking four distinct questions, but they are all closely related: What is my Sprint Goal? How is my Sprint Goal ...


2

Can you change the sprint backlog during a sprint? Can you change the sprint goal? The answer to both questions is yes, but you have to appreciate the implications of such changes. For example, changing the sprint backlog may: Invalidate some or all of your planning Disrupt the team Result in efficiency loss due to context switching Set a dangerous ...


5

This seems to be a good discussion about the usefulness of the Sprint Goal. Let's see... why do you need the Sprint goal in the first place? First, the Sprint goal is meant to provide a roadmap, to the Development team and the PO. It helps to provide guidance as to why the team is building the increment, helps set priorities and offers flexibility when the ...


2

You have a Product Backlog that has User Stories. The Sprint Backlog represents the work that a Development Team needs to pull from the Product Backlog to achieve the Sprint Goal. According to the Scrum Guide After the Development Team forecasts the Product Backlog items it will deliver in the Sprint, the Scrum Team crafts a Sprint Goal. The Sprint ...


1

The reasons why it's advisable not to change the goal of a sprint during a sprint are to allow the team the best chance to deliver the product increment, to help maintain a sustainable velocity and to maintain confidence in the regular cadence of delivery. Ultimately I suggest the PO should take the decision on whether to change the scope during the sprint. ...


3

There are a few things to consider. Regarding "constant pace", the Manifest for Agile Software Development says: Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. This does not say anything about the complexity of work increasing or decreasing over time. It also ...


0

There are some engineering practices that can make this problem easier to solve. For example, the back-end developers can rapidly build stubs and mocks to let the front-end developers start their work. Consider a team working on a new search feature. The steps you can go through might be: Back-end devs create a search API Back-end devs create a stub/mock ...


4

TL;DR This is fundamentally an X/Y problem. The unspoken premise missing from your original post is presumably that your clients don't want to pay for "idle" resources, but that's really just a straw man argument that obscures the lack of collaboration between your teams and the I-shaped people that compose them. The team needs to self-organize around a ...


2

TL;DR Projects change, products evolve, and team composition often needs to change along with them. Slack and reasonable levels of idling are the cost of doing business in an agile framework, but don't be afraid to add or remove people from the Development Team when it measurably benefits the project. Analysis and Recommendations Analysis You may have a ...


1

A similar situation happens with the developer-tester relationship. In simplified terms, at outset there is nothing to test and everything to develop, but at the end of the project the opposite is true. There are several common strategies to deal with this: Blur the role boundaries. For example, developers do some testing at the end. Have the team perform ...


0

There are a few things to think about here. Firstly, how do you define your priorities? If they are only defined at the individual team level then it makes prioritising requests from other teams challenging. Ideally where work is shared there needs to be a clear, top-level prioritisation in place so that is easy for teams to know what they should be ...


6

TL;DR Hold the event daily, even if you don't use the whole time box allocated for the meeting. Don't skip it routinely, even if you think you have good reasons. Doing so may not bite you right away, but it probably will eventually. If you're not finding value in the Daily Scrum, it's likely because the team isn't really performing just-in-time (JIT) ...


13

One of the advantages of having such a small team is that, indeed, the people in the team are able to communicate freely throughout the day. A lot of the daily stand-ups might thus often end very quickly and may look like they are a waste, but they can still have a purpose even in a small team like this: to provide extra focus. The daily standup allows ...


1

There are a couple of things here. Whenever you get new colleagues on a project, they need to load tons of information in their head in order to become productive. That's just how it is. Nobody hits the ground running. They need to learn the project, the business, the rules, the procedures, policies, etc. You can't work on something you don't understand ...


2

Is there some place in this method for new workers who should first "load" tons of information in their heads before they really can start working? Scrum is not only a framework for incrementally delivering value it is also an excellent tool for incremental learning. Teams often start out delivering minimal value as they are going through a sharp learning ...


1

When looking at a group of workers we see the work it took for them to be in the team, they necessarily had to "load" tons of information in their heads before starting to work, or else what lead you to hire them? In the original paper describing Scrum, “subtle control” is noted to be one of the six principles. Selecting the right people for the project ...


0

In Agile it can be useful to think of individuals having a capability rather than a role. Jill has a capability to do development work Sam has a capability to do testing work Helen has a capability to do both development and testing work If our team is full of specialists who can only do one thing, then when we bring work into a sprint it can ...


0

The question to ask yourself is: What information do we want to get from a burndown? Different teams will use the burndown in different ways. A popular approach is to burndown on completed stories. This gives an indication to the team if they are 'back-loading' the sprint, i.e. that stories only get done towards the end of the sprint instead of ...


1

Work is Done or Not-Done Scrum does not require the use of user stories, story points, or burn-down charts. They are commonly used as a best practice, but it's important to understand that they aren't framework requirements. With that said, widely-accepted agile frameworks generally treat work as either done or not-done. Product and Sprint Backlog Items ...


4

What is the definition of work done in Scrum Work that satisfies the Definition of Done, which is defined by the Team. The problem with this is that work being closed on a daily basis is not shown on the Burndown chart This is the correct behaviour. From Scrum's perspective, an incomplete story provides zero value, so the burndown shows zero progress. ...


2

The Scrum Guide states a few things about the Development Team - it is "self-organizing" and no one can tell "the Development Team how to turn Product Backlog into Increments of potentially releasable functionality", that there are "no titles for Development Team members, regardless of the work being performed by the person", there are "no sub-teams in the ...


2

I think DevOps defines the best practices here: specifically the principle of small batch sizes. In other words, if the batch sizes (code commits) are small, then the code reviews can be frequent and short. I would live with the frequency because that's more of an Agile thing and it's OK! Build a team culture that supports it. DevOps also tells us to ...


2

I suspect there is no single answer to this question. Individuals are different. Some may find that doing a code review is a welcome distraction from their coding tasks. Others may struggle with the context switching or may not enjoy doing reviews. Teams are also different. I can see the nature of code reviews varying depending on many factors including: ...


0

It is not the responsibility of a scrum master to do all non-coding tasks. Can this task be put on one or more tickets? This actually looks like two tasks: create new server (List in ticket's Definition of Done: approval gained; get requirements signed off by IT&S; server provisioned; server requirements validated as correct; ...) further application ...


3

Scrum intentionally does not layout exactly how the team will build the product. There are a number of reasons, but most pertinent to this question is that what works for one team may not work for another. Similarly, what works with the tools of the early 2000's may not apply as well today. One of the reasons we work in iterations is because it gives us ...


12

Facilitate Communications; Don't Proxy Them In your specific example, the Scrum Master should function as a communications facilitator, not a proxy for the team. The Scrum Master often functions as a switchboard operator by: Helping team members to identify points of contact outside the team for collaboration and refinement of Product/Sprint Backlog Items. ...


2

You're right that the Scrum Guide is rather vague when it comes to how involved the Scrum Master is when it comes to removing impediments. Personally, I believe that the Scrum Master should, as much as possible, be hands-off for how the team works. The Scrum Master is a single individual. In some organizations, this person may be working as a Scrum Master ...


3

Well, the Scrum Master should help with impediments. You have given no indication that this is an impediment. What makes the email to the head of IT an impediment, unsolvable by the team themselves? The Scrum Master is not the teams errand boy. If the team cannot do it themselves, then the Scrum Master is their escalation step. If it is sufficient to ...


2

One thing I wish to add to the accepted answer, is that you shouldn't take the meaning of the word "Sprint" literally. You see from Thomas Owens' answer that it was a name attached to the way they structured they're work. In a sprint in a sporting event, participants prepare for the sprint (e.g. warm-up), start the sprint when the signal is given, cover a ...


6

Jeff Sutherland, one of the creators of Scrum, provides an answer in his book Scrum: The Art of Doing Twice the Work in Half the Time: And so my team embarked on what we called "Sprints". We called them that because the name evoked a quality of intensity. We were going to work all out for a short period of time and then stop to see where we were. In ...


1

Backlog and 'Fail-fast' are at the very foundation of agile development. In a way, 'Failure in a sprint' is actually a desirable quality. Failed sprint, according to me, is a well-executed sprint. Failure facilitates continuous improvement. 100% success of sprint happens in 2 cases: Team is complacent and is not pursuing ambitious goals. Organization ...


Top 50 recent answers are included