Disclaimer: exported by readmill in no particular order :(
If the product owner has a technical background he might add stories such as “Add indexes to the Events table”. Why does he wa nt this? The real underlying goal is probably something like “speed u p the search event form in the back office
The distinction is quite simple. Stories are deliver able stuff that the product owner cares about. Tasks are non-deliverable stuff, or stuff that the product owner doesn’t care about.
Normally the product owner starts the meeting by summarizing his goal for the sprint and the most important stories. Next , the team goes through and time-estimates each story, starting with the most important one. As they do this, they will come up with important scope questions – “does this ‘delete user’ story include going through each pending transaction for that user and canceling it?’” In some cases the answers will be surprising to the team, prompting them to change their estimates
Pair programming does improve team focus (for example when the guy behind you says “hey is that stuff really necessary for this sprint?”).
We’ve found that pair programming with frequent rotation of pairs automatically leads to a high level of collec tive code ownership. Teams with a high level of collective code ownership have proven to be very robust, for example their sprint doesn’t die j ust because some key person is sick.
Seat the team together!
My experience is that it is better to have fewer teams that are too big than to have many small teams that keep interfering with each other. Make small teams only when they don’t need to interfere with each other!
Isolation: If your whole team were to suddenly stand up and engage in a spontaneous and lively design discussio n, there is nobody outside the team close enough to be disturbed. And vice versa.
One of the first things we did when introducing Scrum was to break up the existing component-specialized teams (approach 1) and create crosscomponent teams instead (approach 2). This lessened the number of cases of “we can’t complete this item because we are wait ing for the server guys to do their part.”
During sprint planning meetings we set the focus factor low enough to account for the time we expect to spend fixing bugs from last sprint. With time, the teams have gotten quite good at estimating this.
We addressed this problem by creating a designated firefighting team, and a designated Scrum team. The Scrum team’s job was to (with the product owner’ s blessing) try to stabilize the system and, effectively, prevent fire s. The firefighting team (we called them “support” actually) had two jobs. 1) Fight fires 2) Protect the Scrum team from all kinds of disturbances, including things such as fending off ad-hoc feature requests coming in from nowhere.
Gradually, over a period of many months, the amount of time spent fixing bugs from previous sprints decreased. In addition we were able to get fewer people involved when bugs did happen, so that the whole team didn’t need to get disturbed each time. Now we are at a more acceptable level.
Pair programming is exhaustive and should not be done all day.
I tend to avoid the term “priority” since priority 1 is typically considered the “highest” priority, which gets ugly if you later on decide that something else is even more important. What priority rating should that get? Priority 0? Priority -1
We try to introduce some kind of slack before start ing a new sprint (more specifically, the period after the sprint retrospective and before the next sprint planning meeting). We don’t always succeed t hough. At the very least, we try to make sure that the spr int retrospective and the subsequent sprint planning meeting don’t occur on t he same day.
If you are Scrum coach (and perhaps also a manager), do get involved as closely as possible. But only for a limited period, then get out and let the team gel and self-manage.
Disadvantage of afternoon scrums: when you come to work in the morning, you have to try to remember what you told people yesterday about what you will be doing today. Disadvantage of morning scrums: when you come to work in the morning, you have to try to remember what you did yesterday so that you can report this.
Shifting pairs frequently is good. Pair programming does improve knowledge spread with in the group. Surprisingly fast too. Some people just aren’t comfortable with pair programming. Don’t throw out an excellent programmer just because he isn’t comfortable with pair programming. Code review is an OK alternative to pair programming. The “navigator” (the guy not using the keyboard) should have a computer of his own as well. Not for development, but for doing little spikes when necessary, browsing documentation when the “driver” (the guy at the keyboard) gets stuck, etc. Don’t force pair programming upon people. Encourage people and provide the right tools but let them experiment with it at their own pace.
Our office environment is too noisy and messy” Typical actions: • try to create a better environment, or move the team offsite. Rent a hotel room. Whatever. See pg 55 “How we arrange t he team room’). • If not possible, tell the team to decrease their focus factor next sprint, and to clearly state that this is because o f the noisy and messy environment. Hopefully this will cause the pr oduct owner to start pestering upper management about this.
But then, long sprints are good too. The team gets m ore time to build up momentum, they get more room to recover from proble ms and still make the sprint goal, you get less overhead in terms of sprint planning meetings, demos, etc. Generally speaking product owners like short sprint s and developers like long sprints. So sprint length is a compromise. We experimented a lot with this and came up with our favorite length: 3 weeks. Most of our teams (but not all) do 3 week sprints. Short enough to give us adequate corporate agility, long enough for the team to achieve flow and recover from problems that pop up in the sprint.
Important: After the sprint planning meeting, our Scrum master manually updates the Excel-based product backlog wit h respect to any changes that were made to the physical story index cards. Yes, this is a slight administrative hassle but we find this perfe ctly acceptable considering how much more efficient the sprint planning meeting is with physical index cards.
Oh, and don’t forget... It’s just a job right?