4 ms·

> If I had to pick the most destructive part of Scrum, it's the sprint commitment. I've organised many XP teams that regularly hit our sprint commitments virtu

> If I had to pick the most destructive part of Scrum, it's the sprint commitment. I've organised many XP teams that regularly hit our sprint commitments virtually every time. The times when I've found it problematic to hit sprint commitments were due to the following: - Sprint was too small. 1 week sprints are awesome, but they are extremely difficult to hit. I run 2 week sprints if I can manage to get people to agree. It can also significantly reduce planning overhead. - Stories were too big. Stories should have a median delivery time of about 1-2 days for a 2 week sprint. The occurrence of 5+ day stories should be in the 1:100 range. High risk stories should always be arranged first in the sprint so that even a 5 day story doesn't blow the sprint out of the water. -Stories were ill-defined. Goes together with the previous point. If you have a really high variance on your stories, it's probably because of this. You should have a "backlog grooming" session once every 2 weeks. At that meeting, you go over any new stories in the backlog and any stories that might make it into the sprint commitment. All developers should attend the meeting. At the meeting you decide: Do you understand what the story means? Could you start coding the story today? Should the story be broken up? It helps if project managers are not in this meeting -- they just respond to the feedback after the fact. Only stories that get the thumbs up, make it into the sprint commitment. - Stories did not have acceptance criteria. Similar to the above, but more specific. Everybody might feel they understand what to do, but if you can't answer the question "How do I know when it is done?" then it isn't a story. In the above cases, you can fairly easily fix the problems and still have sprint commitments. I have also been in some situations where I think sprint commitments didn't match the team. For a variety of reasons, I really like sprint commitments, but it is a bad idea to stick to it if it's not going to work. Here are some situations where I've had problems: - Developers had many disagreements about how/when to merge code. They would take unpredictable amounts of time to merge code. If pressured to merge in order to hit targets, conflict would eventually erupt in the team. -There was a young team that did not know how to relax when there is a deadline. Sometimes they merged inappropriate code just because they are afraid to be the one on the critical path. Sometimes the cut corners for the same reason. If you can pair program, it can really help with this. In these cases, it's a matter of training the team. It helps if you can keep the team together for a long time and if you have a manager who isolates the team from a certain amount of surrounding politics. But sometimes, for a variety of different reasons, it isn't going to work. It's not bad to reach for something else at that point. Sprint commitments can be really beneficial in my experience, but it's one of those things that is the result of having a high functioning team. It's not necessarily the way to make a high functioning team.

vinceguidry 8y ago
How do you organize acceptance criteria? Is it language that has to be added to every story?
- nradov 8y ago
  Every user story should have acceptance criteria (confirmation). Otherwise how will you know when you're done? One common technique for organizing acceptance criteria is to write them in user voice form: "As a <user role>, I want to <activity>, so that <business value>." https://www.scaledagileframework.com/story/ https://www.scaledagileframework.com/story/
  - vinceguidry 8y ago
    Every once in awhile we'll get someone to actually do that. But most of the time the verbiage in the story summary is the acceptance criteria and if there's a problem understanding what is expected, the team lead is the go to person. I was wondering if there's a lighter-weight way of specifying acceptance criteria, or a framework for deciding which stories need additional criteria specification.
    - nradov 8y ago
      The Product Owner is accountable for distilling user requirements into proper user stories, including acceptance criteria. (Other team members can help with that but the PO is accountable.) POs who don't do that consistently need to be retrained or replaced. And the Scrum Master has to be a gatekeeper. During sprint planning if a user story lacks proper acceptance criteria then it stays in the backlog for further refinement.
      - mikekchar 8y ago
        Yes, I think this is exactly right (not just in what Scrum/XP says, but also in how it has to be). Separating that role is super important and is potentially one of the friction points in transitioning from a more traditional setup (as evidenced by TFA). In my experience, it is also very, very important that the Scrum Master is not the manager of the team. It has to be someone whose accountability is to the technical success of the team as distinct from the delivery of high level objectives for the team. In a more traditional setup that would be someone like a team lead, senior dev or even a system analyst. XP doesn't define this role specifically and it is probably a weakness -- I've done it as a coach, but usually I appoint someone on the team to do it. Also, interestingly, I've often had project managers who refuse to do the PO role (I usually call it the "Customer Proxy", but it's the same role). In those cases I try to appoint someone who is accountable for writing stories. They consult with the project manager for the higher level "vision" (but in practice the project manager does virtually nothing -- a state of affairs which they are usually quite familiar and comfortable with, unfortunately). Prioritisation of stories is done by the development manager, PO and project manager (if they are different from the PO). In this case, the Scrum Master/Coach is not invited to that meeting. To answer the original question: How do you represent the acceptance criteria? Personally, I do not like code based representations of acceptance criteria. Having said that, my entire exposure to them is working on legacy projects where they have gone badly wrong. The main problem is the same problem with trying to maintain prose documentation of the requirements of a large system -- those requirements are at least as long as the implementation of the system. They are also at least as complicated. We've slowly created ways of organising production code to make it easier to manage. The same is not true for BDD style acceptance criteria, or even prose requirements documents. At the beginning of my career I spent a lot of my time writing requirements documents in prose. Every 6 month release would include something like 1300 pages of requirement documents. Maintaining these requirement documents was impossible. Very quickly they get out of date and so you no longer have any description of the working code other that the implementation itself. Based on these experiences, my attitude is that requirements (including acceptance criteria) are ephemeral. They exist for the life of the story and then you abandon them (note: I'm still massively in favour of acceptance tests and unit tests, but implemented as code that is written in a similar way to the production code -- because we have techniques for managing that complexity). Long story short: I write them in prose on the story and appoint someone to making the determination whether or not the acceptance criteria is sufficient to add the story to the sprint commitment (as nradov explained in much fewer words than I did :-) ).

vinceguidry 8y ago

How do you organize acceptance criteria? Is it language that has to be added to every story?

nradov 8y ago
Every user story should have acceptance criteria (confirmation). Otherwise how will you know when you're done? One common technique for organizing acceptance criteria is to write them in user voice form: "As a <user role>, I want to <activity>, so that <business value>." https://www.scaledagileframework.com/story/ https://www.scaledagileframework.com/story/
- vinceguidry 8y ago
  Every once in awhile we'll get someone to actually do that. But most of the time the verbiage in the story summary is the acceptance criteria and if there's a problem understanding what is expected, the team lead is the go to person. I was wondering if there's a lighter-weight way of specifying acceptance criteria, or a framework for deciding which stories need additional criteria specification.
  - nradov 8y ago
    The Product Owner is accountable for distilling user requirements into proper user stories, including acceptance criteria. (Other team members can help with that but the PO is accountable.) POs who don't do that consistently need to be retrained or replaced. And the Scrum Master has to be a gatekeeper. During sprint planning if a user story lacks proper acceptance criteria then it stays in the backlog for further refinement.
    - mikekchar 8y ago
      Yes, I think this is exactly right (not just in what Scrum/XP says, but also in how it has to be). Separating that role is super important and is potentially one of the friction points in transitioning from a more traditional setup (as evidenced by TFA). In my experience, it is also very, very important that the Scrum Master is not the manager of the team. It has to be someone whose accountability is to the technical success of the team as distinct from the delivery of high level objectives for the team. In a more traditional setup that would be someone like a team lead, senior dev or even a system analyst. XP doesn't define this role specifically and it is probably a weakness -- I've done it as a coach, but usually I appoint someone on the team to do it. Also, interestingly, I've often had project managers who refuse to do the PO role (I usually call it the "Customer Proxy", but it's the same role). In those cases I try to appoint someone who is accountable for writing stories. They consult with the project manager for the higher level "vision" (but in practice the project manager does virtually nothing -- a state of affairs which they are usually quite familiar and comfortable with, unfortunately). Prioritisation of stories is done by the development manager, PO and project manager (if they are different from the PO). In this case, the Scrum Master/Coach is not invited to that meeting. To answer the original question: How do you represent the acceptance criteria? Personally, I do not like code based representations of acceptance criteria. Having said that, my entire exposure to them is working on legacy projects where they have gone badly wrong. The main problem is the same problem with trying to maintain prose documentation of the requirements of a large system -- those requirements are at least as long as the implementation of the system. They are also at least as complicated. We've slowly created ways of organising production code to make it easier to manage. The same is not true for BDD style acceptance criteria, or even prose requirements documents. At the beginning of my career I spent a lot of my time writing requirements documents in prose. Every 6 month release would include something like 1300 pages of requirement documents. Maintaining these requirement documents was impossible. Very quickly they get out of date and so you no longer have any description of the working code other that the implementation itself. Based on these experiences, my attitude is that requirements (including acceptance criteria) are ephemeral. They exist for the life of the story and then you abandon them (note: I'm still massively in favour of acceptance tests and unit tests, but implemented as code that is written in a similar way to the production code -- because we have techniques for managing that complexity). Long story short: I write them in prose on the story and appoint someone to making the determination whether or not the acceptance criteria is sufficient to add the story to the sprint commitment (as nradov explained in much fewer words than I did :-) ).