Spike is an investigation in technical or business domain with the purpose of enabling further work on “real”, functional user stories. Technical spike has a purpose of learning certain technology to be able to estimate if it is appropriate for the implementation of a concrete feature or a set of features. Functional spike has a purpose of learning business domain and/or solving a functional problem which will further enable implementation of a feature or a set of features.
The software we are building is a complex system. A human body is a complex system too. Sometimes, when you get sick, it is very simple for MD to recognize the symptoms and to make a diagnosis. Based on that, she will prescript your therapy and the most of the times, you’ll be well after a week or two. Continue reading
When I was first introduced to Scrum, I thought “What an easy and beautiful way to be efficient!” After years of doing Scrum, I found that it’s not that easy. It was easy to learn. And, as many times before, “easy come, easy go” was true. It was very easy forget easily learned facts of Scrum. I’ll tell you about some of the traps me and my friends experienced during Scrum implementation. Solving these was more or less successful, but if you recognize at least one of them in your environment, which you weren’t aware of before, my article was a success. I will tell you five real stories about people who were on the edge of Scrum and how they succeeded in avoiding Scrum traps. My Scrum heroes’ names have been changed to protect their identity. Let’s begin.
Proxying Product Owner
“Beware of the ScrumMaster who thinks that he can permanently assume the Product Owner role,” I would say. I’ve heard a similar saying before, “A good ScrumMaster can handle two teams and a great one can handle only one.” If you try to do the ScrumMaster and Product Owner role at the same time, you’re doomed. You won’t be able to perform both roles correctly – that’s certain.
One day, Scott was told at the very end of a Sprint that the Product Owner on the project had to move to another project that had stalled. He was told to act as Product Owner proxy for some time. Scott and the team were in a highly dynamic and quickly changing business, and it was a pretty tough period for the team. The first issue Scott was facing was time. The Sprint was one week long, and he did partially succeed in resolving impediments and barely succeeded in preparing acceptable user stories during the first Sprint. The second Sprint was a total disaster. Impediments started to pile up, and Scott didn’t succeed in preparing acceptable user stories. The Product Backlog was filled with a few essays, without good, smaller user stories. And Scott was a pretty good problem solver. He would have certainly been a great Product Owner, if he was focused only on this role. Simply, Scott didn’t have enough time to do both roles well for the team. Another issue Scott experienced was context switching, but maybe this is the wrong term. A better term is perspective switching. That was very stressful. At one moment Scott was trying to solve impediments and at another trying to figure out which story would return the investment in the best way. How did Scott deal with this? He didn’t. He told the stakeholders to delegate a new Product Owner. Even a non-experienced Product Owner is a better solution than a ScrumMaster acting as Product Owner proxy. Luckily, Scott’s Product Owner returned and he was able to keep Scrum on the track.
ScrumMaster as a Team lead
Claire had a pretty strong technical background on system administration, networks, and Java software architecture/development. Top management considered this to be a great asset to the team she was supposed to serve as a ScrumMaster. Because top management had a foggy understanding of Scrum, Claire was considered to be a “Team Leader.” Claire was the most experienced programmer in this team, but didn’t even have the role of developer. The other team members were really great developers and quick learners, but new to Scrum. They didn’t quite understand the nature of her engagement in the project, even though she had tried to be pretty clear about her role. They knew Claire before this project and had respect for her as a developer. I suppose they expected her to deal with technical issues using her remarkable experience. This asset started to become a great burden for the team and for Claire personally. She knew that if she got deep into coding she wouldn’t be able to act as a good ScrumMaster. The first Sprint Planning Meeting started, but when technical debt was discussed, everybody looked at her, expecting her valuable opinion. She remembered something that she heard once from a more experienced Scrum Coach. She asked the team to excuse her for some time and to continue the technical discussion without her. They were surprised, but after she left, they did continue. After some time she returned and they barely noticed her. She was satisfied with the result. When the meeting was finished, she asked the team if everything was ok and how they decided to address technical solutions. Everything was fine and the team was satisfied because they handled everything themselves. She suggested that they would feel better if they made decisions on technical stuff, and that they were very good developers. “Of course,” she said, “I’ll give suggestions if needed, but I’m not supposed to make decisions. The team has the power to decide. My job is to serve the team and to be sure that the project and work are running smoothly.” Claire made an “impediment list” sticky note on the wall and asked the team to give her tasks whenever they wanted, no matter what issues they might have. Then they really understood her role on the project.
Support Departments Don’t Use Scrum
Robert was a Scrum Coach for a software department that developed in-house projects. They had used Scrum for almost a year, and were doing a great job. When Robert came to the company, the department was pretty messed up, but in a few months everything fell into place and the teams became hyper productive. This was recognized by top management, teams were regularly awarded, and everything was fine. But Robert was a little worried. At first, he was focused on the teams, and wasn’t able to see the whole picture. Using Scrum, real issues were surfacing, but he was focused on the issues he had influence over, and the team was solving them. So, when impediments inside the department were minor, other impediments became visible. The first sign of trouble was that the Product Backlog was pretty empty. He talked with Product Owners and discovered that they couldn’t get enough information to create acceptable user stories. “Why?” he asked. Simply put, nobody from other departments had the time to define what they needed, and when they needed some functionality, they needed it immediately. From his perspective, communication with other departments was an impediment, but he felt responsible to initiate the solution. Now, because teams were pretty self-organized and doing well, it was time to spread Scrum to the other departments. First he talked to top management about the situation in other departments and presented the idea about introducing Scrum. They hadn’t originally considered it, but were pretty satisfied with the re-organization of the software department, so they agreed. Robert explained that he didn’t want to make this transition top-down, but would try with volunteers. He invited heads of each department to a working breakfast and explained Scrum, presenting potential benefits for the department using its principles. He asked them to bring a few team members to the next three meetings about Scrum. They were pretty shocked when he introduced some of the Scrum games, expecting a PowerPoint presentation. “Hey, you didn’t even bring your laptop,” they said. “I don’t need it,” Robert replied. After playing two games, he conducted a practice retrospective meeting, allowing the teams to reach their own conclusions. Then he helped them to make parallels with real situations that they were dealing with. It was quite refreshing and revealing for most of them. Then, he explained that Scrum was not a silver bullet, but a tool that could help them to understand the impediments and to enable them to work better. He asked them to consider it and to let him know if they would like to try Scrum in their environment. The next day, the chief of the technical support department contacted Robert, claiming that his team was overwhelmed and eager to try Scrum. “Great!” Robert said. “Let’s start preparations for our first Sprint.”
Disputed Definition of Done
Ulrich was a pretty experienced Scrum Practitioner. He knew that coaching a new team was going to be tough. They were all experienced programmers, but new to Scrum. Initially, coaching was tough, with much resistance and conflicts; a bumpy road that was now almost behind him. Eventually, things were much smoother because he knew the team’s velocity and the team knew their velocity, which was much more important. Velocity was regarding to “DONE DONE” user stories. He remembered the issue the team had with this, their definition of done (DoD). As he explained at the very beginning, the team and the Product Owner had to reach an agreement on this. One of the guys came up with a DoD proposition, and the team and the Product Owner were ok with it. One of the items in this list was “unit test coverage of 80%.” After the first few stories were “done,” he asked the Product Owner to test the items from these stories. With the tool they had, it was easy to see a unit test coverage of 23%. Ulrich asked the Product Owner what he thought about that. He answered that he wasn’t satisfied with that the result. “Why?” asked Ulrich. “Because these stories are not done,” replied the Product Owner. “Do you need a unit test coverage of 80%?” asked Ulrich. “No, I don’t know why they chose these figures, but if the team defined these, I expect them to meet these criteria,” answered the Product Owner. And he was right. The Sprint ended the next day, and during the Sprint Retrospective, Ulrich announced that the Sprint had failed, which provoked a very emotional response from the team members. He explained the reason and showed them real figures on test coverage. “But why is this important? We did all the necessary tests. We didn’t want to waste time unit testing trivial methods, such as getters and setters, and we didn’t want to test something covered in integration testing,” screamed the guy who purposed the DoD criteria. “Yes, you are completely right, but you promised something about unit testing and this was not accomplished. Could you tell me how you determined the proposed DoD?” Ulrich asked. “Well, I didn’t know what criteria to propose, so I copied some from a Scrum blog, which looked great at this time.” “Ok, guys,” Ulrich said, “this is my failure as Scrum Coach as well and it’s my fault that you didn’t understand the meaning and importance of DoD. DoD is different from team to team and project to project. This is not a general standard that should be implemented in all situations. And Scrum is not a standard that can be implemented the same way in all situations. Those are tools, which help you make better software, but you need to involve your intelligence, energy and creativity to make it happen. Ok, let’s do the job. Let’s create a DoD acceptable to us and our Product Owner. You are experienced developers and you know everything about good programming practices. You’ve seen one of many possible DoD’s. Let’s make new a DoD we can commit to.”
Estimations in hours
Marianne was inexperienced, but passionate about Scrum. She started her first Scrum project with the team and was thrilled, anticipating her first ScrumMaster job. The team knew about Scrum and was interested in trying it. Before the first Sprint Planning Meeting, the Scrum team agreed on some conventions and one of them was estimating user stories and tasks in hours. This was the natural choice for the team and Marianne agreed with that. Estimating in user story points was awkward to the team, since they couldn’t figure out how to correlate this to some real measurement unit. So they started their Sprint meeting and started estimating. They estimated all user stories and chose ones they could commit to finish until the end of Sprint. Then, the Product Owner stood up and spoke. “Well, guys, you just committed to finish user stories worth 230 hours and you have 400 working hours in your Sprint. Even if we add 30 hours for the meetings during the Sprint, still there’s 140 hours in the Sprint you should commit to. Is my math correct?” “Yes, you’re right,” said the senior developer, “but a working hour cannot be equal to a development hour. We have to have time to think about the story, business process, architecture etc. So, coding functionality is not the only job we’re working on. Development is the intellectual process, not an exact, simple operation. We really didn’t underestimate, in my opinion, and we didn’t want to „steal’ some time. I just feel that we cannot commit to more than we already did.” “Ok guys,” continued the Product Owner, “I believe you were honest with the estimations and I think that this is a fine velocity if you meet those commitments with your definition of done. I just can’t figure out this difference and it would be difficult for me to explain this to the stakeholders.” It was good timing for Marianne to do some facilitation work. “The way I see it,” she said, “we have a problem with the measurement unit. The Product Owner is satisfied with the features to be developed in this Sprint, but somehow user stories measured in hours don’t provide the real information, correct? Furthermore, this difference in time is causing confusion. If developer hours cannot linearly correlate with real time, why don’t we say points, not hours? After a few Sprints, we will be better in our estimations in these points, correct? And there will be no confusion with working hours and time. After a few Sprints, we will know our velocity in these points and will have more experience in estimating work. Stakeholders will get their graphics in these points and will be able to monitor progress daily. What do you think?” The Product Owner was delighted with this idea, knowing that he’d be able to show diagrams to the stakeholders in real time, and the team was relieved from the pressure they felt after Product Owner’s speech. Marianne scored her first small victory helping her team to overcome its first impediment and potential conflict. After a few Sprints, they got used to estimations in user story points, so it came naturally to them.
I hope that you enjoyed these real Scrum stories and that you can recognize some of the situations in your everyday Scrum practice. Please comment on them and comment on how you would deal with these situations.
Remember you are looking to develop slices of the business opportunity the produces valuable working software with the potential to generate feedback from users. Sometimes the story slices are not deliverable to end-users but they generate value from the learning gained in producing them. They should all result in testable and demonstrable software. Consider applying the XP principle DTSTTCPW (“Do The Simplest Thing That Could Possibly Work”)
Consider the following approaches:
What are the visual elements that must be there or can be deferred?
- You can make a story per viewing steps on a user journey.
- You can make a story per enabled elements of an input screen.
- You can make a simple (not pretty) UI.
- You can make a command line interface.
What scenarios are in scope for acceptance criteria?
- You can work with a subset of the user scenarios.
- You can defer conditional steps to other stories.
- You can defer data validation.
- You can defer error handling.
What architecture decision or constraints that can be deferred?
- You can defer optimization of performance.
- You can defer internationalization
- You can defer working on different platforms/devices
- You can defer handling large volumes of data.
- You can hard-code data rather than getting from the real source
- You can stub out components.
This is not an exhaustive list! Be creative in your story splitting approach.
Concept: Crowdsource your wedding photos
Invite guests to contribute and view collected photos from event
Benefits: personal photos – longer timeline including build up to big day – cheaper
Costs: web hosting, storage, charging model 5p per upload, 10 per published photo
Challenges: privacy, participation, selecting
Personas: Kim anxious bride, Geoff non-techie guest, Alex always-on-social media mate.
Here are some headline “Epic” stories:
- Happy couple: Invite guests to contribute photos
- Guests: Upload photos
- Happy couple: Select photo set to share
- Guests: Add information about photos
- Guests: View photos
- Get into groups of 2-3 people
- Grab some index cards
- Consider one epic story
- Write smaller stories, one per card
- Objective: as many small story cards as you can
- Share one small story with the group at the end
Note: Taken from Rachel Davies, 2014 Agile Adria event
Following are the steps the team took to change this endemic challenge of focusing on what they could not change. Note step 7. All of the steps are critical in the process, and step 7 is the one that will take your team to the next level – it is Follow-Up – and it will ensure that the change sticks!
1. Ask all members of the team to confidentially record their individual answers to two questions: (1) “On a 1 to 10 scale (with 10 being ideal), how well are we doing in terms of working together as a team?” and (2) “On a 1 to 10 scale, how well do we need to be doing in terms of working together as a team?”
2. Have a team member calculate the results. Discuss the results with the team. If the team members believe that the gap between current effectiveness and needed effectiveness indicates the need for team building, proceed to the next step in the process.
3. Ask the team members, “If every team member could change two key behaviors that would help us close the gap between where we are and where we want to be, which two behaviors we all should try to change?” Have each team member record his or her selected behaviors on flip charts.
4. Help team members prioritize all the behaviors on the charts (many will be the same or similar) and (using consensus) determine the most important behavior to change (for all team members).
5. Have each team member hold a one-on-one dialogue with all other team members. During the dialogues each member will request that his or her colleague suggest two areas for personal behavioral change (other than the one already agreed on above) that will help the team close the gap between where we are and where we want to be.
6. Let each team member review his or her list of suggested behavioral changes and choose the one that seems to be the most important. Have all team members then announce their one key behavior for personal change to the team.
7. Encourage all team members to ask for brief (five-minute), monthly three question “suggestions for the future” from all other team members to help increase their effectiveness in demonstrating 1) the one key behavior common to all team members, 2) the one key personal behavior generated from team member input, and 3) overall effective behavior as a team member.
8. Conduct a mini-survey, follow-up process in approximately six months. From the mini-survey each team member will receive confidential feedback from all other team members on his or her perceived change in effectiveness. This survey will include the one common behavioral item, the one personal behavioral item, and the overall team member item. A final question can gauge the level of follow-up – so that team members can see the connection between their level of follow-up and their increased effectiveness.
This process works because it is highly focused, includes disciplined feedback and follow-up, doesn’t waste time, and causes participants to focus on self-improvement.
Let me close with a challenge to you (the reader) as a team leader. Try it! The “downside” is very low. The process takes little time and the first mini-survey will quickly show whether progress is being made. The “upside” can be very high. As effective teamwork becomes more and more important, the brief amount of time that you invest in this process may produce a great return for your team and an even greater return for your organization.
Originally from: http://ll.rs/rDrn, Author: Marshall Goldsmith
As a Product Owner your main duty is to keep Product Backlog in a great shape, in condition which is enabling developers to work on PBL items. So, this is what you need to take care about:
- Keep user stories prioritised – uniquely. There can’t be two user stories with the same priority.
- Keep your user stories READY (by Definition of Ready*) at least two sprints ahead.
- Keep your user stories granular enough for the team to finish each user story within a sprint.
- Keep your user stories grouping – may each user story belongs to feature set/epic/theme.
- All user stories for at least next two sprints should be estimated by the team. Preferably, have all PBL user stories estimated (at least roughly).
- All user stories for the next two sprints must have the acceptance criteria.
- All future user stories or epics must have at least feature acceptance criteria.
- For all user stories for the next two sprints keep list of necessary resources. Keep critical resources marked RED.
- Keep all items (technical tasks, bugs,…) prioritised and READY
- Keep all user stories for the next two sprints refined by the development team.
*Definition of Ready – each user story needs to fulfil these criteria to be accepted as ready for the development
- User story has: title, description, acceptance criteria.
- User story has all necessary resources prepared.
- All user stories which original user story is dependent on are done.
- User story has unique priority defined.
- User story is accepted by the development team.
Based on Dan Pink’s articles and books, money can be a motivator for jobs without great uncertainty and mostly in mechanical jobs, with very small degree of expected innovation and creativity. When non-linear productivity is present, with great degree of uncertainty and where innovation and creativity do finishing the job, there are three main motivators:
How this fits in the team. For years, I’m working with software teams, where all aforementioned conditions are fulfilled. The degree of uncertainty is big, estimations are just lucky guesses, more or less depending on different factors. Also, finishing the software depends on developers’ experience and creativity or ability to use this experience in new situations. Of course, there will always be projects doable by one developer, but, as I mostly work within the teams on very complex projects, with several multi-functional and specialized teams, I’ll be writing about setup of an agile team. Agile movement has become a mainstream in software teams and embracing agile principles brought many goods to people, teams, projects and organizations. Agile comes in many forms (like Scrum, Lean,…) and there is no “one-fits-all” solution and even more, believe or not, Agile does not fit in all organizations and projects. Now, when I made this statement, I’ll also make a statement, which I deeply believe based on my experience – if you can bring your team really to believe in agile values and principles, embracing and implementing it through the practices, it will almost certailnly bring good to your team members, project and organization.
Many people, specially on conferences speak about agile topics as a holy grail, mostly in vague and abstract way, showing that they have little or no concrete experience working with the real projects, the real projects, solving the real issues. I’ll try to speak about concrete experiences I had with the team motivation, from abstract level, going deep dive towards concrete practices and solutions I implemented. Once again, don’t take it as a prescriptive thing – there is no “one-fits-all” solution, but hearing about my experience might be good for your imagination and creativity in case you come in some similar situation.
Team motivation is starting from individual motivation to work on project, with certain technology, within a certain team etc., so all of Dan Pink’s motivation factors apply. But, that’s not all. Within the team more complex rules apply. Also, all these rules and complexities can be observed through the prism of Pink’s rules. Let’s see how they apply.
Autonomy in the context of team might sound crazy, having in mind that all decisions, estimations etc. are done by the team. On the other hand, every single team member is expected to contribute the team with her unique knowledge and experience in bringing estimations, decisions and finally the work which needs to be done. Since amount of work is split, every team member should be able to autonomously take the task/user story, autonomously to bring it to finished state. Of course, she can count on team members’ help. But, her own competence is expected to be team’s strength, not the weakness. So, working alone or in pair, team members use their skills, experience and competences to autonomously bring solutions to the project. Finally, the work is supposed to be done by a person, autonomous and highly respected within the team. So autonomy doesn’t sound so crazy any more. Invididuality should bring new value, a new flavour to the team, project and the organization – should boost the project.
Working alone, as a freelancer for example, might bring a lot of autonomy to the person, a lot of responsibility, but will draw back possible improvement to the highest mastery levels. Not having anyone to discuss with about the possible solutions, new technology, to challange her/him about proposed solutions is pretty damaging for the loner’s mastery. On the other hand team members are pushing each other to the boundary limits, challanging each other with solutions suggested, opening new worlds to each other, exchanging knowledge, experience and soft skills. Mastery inside the team is encouraged and assisted. Having Google, articles, books as a support is good, but having another living developer creature by your side is irreplacable.
Feeling belonging to the team, fulfilling purpose within the team on a great project is really overwhelming. Also, team achieving a goal usually brings a feeling of greater purpose to the individual. Every team member has her own/individual agenda and fulfilling her own plan, within an team, encouraged and assisted by the team also brings sense of the purpose fulfilling to the individual.
Why estimation is important?
Estimating prioritized backlog, we are making transparent to business side what (roughly) can be done in the following period. Estimations in time are dependent on may factors: experience of the developer, we need to know who will exactly work on this if we want to estimate – and this is usually not known in advance etc.
For these and many other reasons, we prefer to estimate in user story points (USP). USP is virtual unit and is based on experience and knowledge of your product backlog. The idea of USP will be learned with time and calibrated within the team.
Basic idea with USP is that this is measure of total efforts needed for delivering one user story. It is relative estimation of one user story to the other one. I will give you few hints for having better estimations.
Hints for estimate:
- Choose the smallest, but still complete (carrying business value) user story and mark it with 1;
- Choose something twice (by your sense – take an engineering approach) bigger user story and give it 2;
- Continue with relative estimations, using 1, 2, 3, 5, 8, 13, 20, 40
- If you have A=1 and B=2 and C in the middle, use your experience to estimate if C is closer to 1 (A) or 2 (B). Mistakes are allowed and even welcome in the process of learning to estimate as a team and getting more experience in this activity
- Estimation is the process, not deterministic, but rather experiential. Give the best estimation based on previous instructions, but have in mind that these estimates will be better with time.
- In my experience, it takes 3-4 sprints for the team to stabilize the estimates on team level and to get necessary experience for stable estimates and stable velocity on sprint level
- Avoid having 13+ user stories in sprint backlog, even in closer (in time) product backlog. If you have 20 USP user story insist on splitting it to several user stories (at least two). If it is not possible, plan splitting to tasks and several people working on this user story to mitigate the risk of not delivering it by the end of sprint.
- Each user story sizing should be appropriate for delivering it in one sprint, i.e. each user story should be deliverable/doable in a sprint;
- Good practice, during the second part of sprint planning, is to split each user story to the tasks. Ideally, each task should be doable in a day – this way it is easy for the team to see daily progress (on daily scrums)
At last, feel free to make a mistake, as long as you give your best estimate. You will, individually and as a team, learn and become better in time.
- Gives stakeholders (rough, more or less) idea about features and project size;
- Ignites the discussion within a team;
- Team is learning through process of estimation
- Estimates are usually wrong;
- Time for a team to estimate is a waste;
- Estimations in time
- Force small (comparable) size of user stories;
- No time (waste) for estimation – start working immediately;
- Client is blind for deadline;
- Needs great trust in team;
- possibly no discussion in planning phase;
- possibly big user stories in sprint breaks the concept;
- User stories need to have business value – sometimes splitting user stories are loosing business value.
- Coding is done according to agreed coding standards. Rules of compliance are at least x%
- Code is properly documented
- Peer(s) reviewed the code carefuly and at least N approvals received
- Unit tests are written and passing
- Acceptance tests are automated according to acceptance criteria and passing
- All code written is pushed to the reporsitory
- CI system successfully builds with the newly pushed code. Build with tests is green/sunny
- Documentation on wiki is written or updated
- Overall code (test) coverage is minumum Y%
- All strings are Localised and IDs are updated on wiki
- All sub-tasks are done and JIRA is updated