I get a lot of questions about how we do this project. I’m going to start with describing the process in this post and am already preparing a follow up about the actual development. Comments and questions about our process are most welcome, but if it’s something about the development you might be better off wait for that post. That being said, here’s how we do it, the process part.
Our cycle (re)starts on Thursdays. Each Thursday before lunch we meet our customer to make sure we're on the right track. Since we have decided on two week iterations, every second Thursday we first have a sprint demo and then (re)prioritize all remaining stories in the backlog. The other Thursday we just discuss issues from the first half of the iteration and status of other ongoing tasks - i.e. stuff that people outside the team are doing. That may be setting up the production servers in the customers’ environment for example.
On the sprint ends we have a retrospective where the whole team, except the customer, get together and discuss the sprint. At first we had it before the customer meeting with the demo, but we always had to rush it in the end to get done before the customer came. Once we invited the customer to join or retrospective, but since the involvement during sprints is so low the customer didn't have much to say. Hence we decided we'd keep doing without and moved the retrospective to after lunch. The time before the customer arrives we now use to prepare for the demo.
The next step in the process is the task breakdown of the top prioritized stories. We get the whole team together and the Interaction Designer, who has somewhat the role of the on-site customer, will walk us through the stories and show the prototype. We take the the stories one-by-one and after the walkthrough we break down the story to tasks. When the breakdown is complete we play Planning Poker to estimate each task in measure of days, with half a day being the lowest estimate. Tasks a lot smaller than that we try to merge together.
When we had the retrospective before lunch we had task breakdown after lunch. I felt we needed some more slack to really end the first sprint before starting a new one though, so that was another reason for changing the meeting calendar. As we moved the retrospective to the after lunch slot, we now break down the stories on Friday after our daily standup meeting. I feel that it gives us a lot better rhythm. That also leaves some air on Thursdays to execute some ideas from the retrospective and deal with some technical debt.
Speaking of the daily standup we have it each morning at 9.15 except for Mondays, when we have a general meeting for the entire company at that time, and have our standup after that. We have all done Scrum before and have learned to value the daily standup meeting a lot. That’s about all we took from Scrum that doesn’t exist in XP though, except maybe the role Board Master that we invented to have some responsibility for our Kanban board.
We have the standup meeting in front of the Kanban board. Our board now has the columns Selected, Development, Test and Done, where the Development column is split into three sub columns - In progress, Trash and Ready for Test. The trash column is the only addition from our original board. It is used for collecting all tasks before they are all done. When all tasks are done we will move the story card to Ready for Test and the trashcan can be emptied.
Showing posts with label User story. Show all posts
Showing posts with label User story. Show all posts
Tuesday, February 9, 2010
Friday, October 23, 2009
Presenting XP - our XP
I just held my fourth presentation of XP this month. The first was on the startup meeting, the second with the team, the third was for the customer and today it was for the entire tech department of Creuna Sweden.
The first occation was alot about selling the idea to the company. That presentation was based on the article What is XP by Ron Jefferies along with a couple of slides I added about why this was good for us, both in this project and in the long run. On the rest of the presentations I have just had one slide, One Page XP by Bill Wake, and talked freely about XP from upper left to lower right, adding things as I pass the different stages.
The second occation was to get the team started, trying to figure our the roles and responsibilities among us. What are the Interaction Designer, the Test Leader and the Project Manager supposed to do? We've decided on having the Interaction Designed being in charge of the user stories, and coordinating them with the customer. Along with the Test Leader she then writes proposed Acceptance Tests for each story. The Test Leader is then in charge of implementing the Automated Acceptance Test using Selenium and also doing the manual testing where Selenium can't be used. The Project Manager mainly do XP while playing The Planning Game and keeping the Overall Schedule. Other than that she keeps track of how we're doing with time and estimates and arrange everything around to let the rest of the team focus on producing - she's somewhat like a Scrum Master.
The third was more of a introduction where we wanted the customer to know what to expect and to get to know how much the customer wanted to be involved. We got the customer to agree on sitting one day every week at our office, and also got to know that more involvment in the story creation was wanted. We settled for a process where Angelina will produce the stories and then walk the customer through them in a separate meeting before we plan. It's a solution we all think will work really good.
This last one was more educational to let everyone else at the company know what XP is, what it can do for us and what pros and cons we've found so far. About half of the group knew briefly what XP is on before hand, but only a few had more than shallow knowledge. The most discussion was when I came to the Design Philosophy box in the lower left where we talked about Good Design versus Simple Design. I stated that all Design Principles still are valid and that Simple Design just states that you shouldn't make your design "future proof". An example that came up was that you might not want to use a Factory for creating objects if you only can see need for one implementation, which I agreed to but added that you'd anyway would make that class implement an Interface that others use to access it - making it easy to add a Factory later on if needed while it isn't adding code that isn't needed. I found it peculiar that no discussion at all was raised around Pair Programming - except our thought about how to deal with new developers added to the team.
The first occation was alot about selling the idea to the company. That presentation was based on the article What is XP by Ron Jefferies along with a couple of slides I added about why this was good for us, both in this project and in the long run. On the rest of the presentations I have just had one slide, One Page XP by Bill Wake, and talked freely about XP from upper left to lower right, adding things as I pass the different stages.
The second occation was to get the team started, trying to figure our the roles and responsibilities among us. What are the Interaction Designer, the Test Leader and the Project Manager supposed to do? We've decided on having the Interaction Designed being in charge of the user stories, and coordinating them with the customer. Along with the Test Leader she then writes proposed Acceptance Tests for each story. The Test Leader is then in charge of implementing the Automated Acceptance Test using Selenium and also doing the manual testing where Selenium can't be used. The Project Manager mainly do XP while playing The Planning Game and keeping the Overall Schedule. Other than that she keeps track of how we're doing with time and estimates and arrange everything around to let the rest of the team focus on producing - she's somewhat like a Scrum Master.
The third was more of a introduction where we wanted the customer to know what to expect and to get to know how much the customer wanted to be involved. We got the customer to agree on sitting one day every week at our office, and also got to know that more involvment in the story creation was wanted. We settled for a process where Angelina will produce the stories and then walk the customer through them in a separate meeting before we plan. It's a solution we all think will work really good.
This last one was more educational to let everyone else at the company know what XP is, what it can do for us and what pros and cons we've found so far. About half of the group knew briefly what XP is on before hand, but only a few had more than shallow knowledge. The most discussion was when I came to the Design Philosophy box in the lower left where we talked about Good Design versus Simple Design. I stated that all Design Principles still are valid and that Simple Design just states that you shouldn't make your design "future proof". An example that came up was that you might not want to use a Factory for creating objects if you only can see need for one implementation, which I agreed to but added that you'd anyway would make that class implement an Interface that others use to access it - making it easy to add a Factory later on if needed while it isn't adding code that isn't needed. I found it peculiar that no discussion at all was raised around Pair Programming - except our thought about how to deal with new developers added to the team.
Thursday, October 22, 2009
Planning Poker
Today Tommy brought his Planning Poker deck to our Planning Game session (see previous post). I've only read about planning poker before but never used it in practice.
The Deck:
The Planning Poker deck is like an ordinary deck of cards but instead of clubs, diamonds, hearts and spades with different values there are only numbers representing days. On the back of each card there is a color to group them. Each color consists of thirteen cards numbered 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100. It also have two "wildcards", one coffeecup meaning take a break and one question mark meaning we have to discuss this.
Planning Poker Deck
Game play:
We were four players. Each player picked a pile of cards with the same color. As in most card games you are not supposed to show you cards face to your competitors. Then we read one of our User Stories and each player played the card representing the number of days they believed it would take to finish it. Estimates included automated acceptance tests as this is the definition of done in our case. The card you played was placed at the table with face down, and then turned by all players simultaneously so you wouldn't cheat:) If all players played the same estimate this estimate was written down on the User Story. If all players played different estimates we discussed back and fourth until we all felt comfortable with the estimate. Equally if some player played a much higher or lower value than the rest of us. The coffeecup or the question mark was not used, maybe next time.
Even though there's no real competition as there are no winner, except the whole team if the estimates are good, it was much more fun than just sit down and do estimates. I really recommend you to try it.
The Planning Game
Today we played our first Planning Game. We started this morning with playing Planning Poker to estimate all the stories we've come up with. It turned out really good, but we didn't manage to estimate all the stories on the hour we had before the customer arrived for the Release Planning and Iteration Planning. A small pile of assumed low priority stories remained, but we probably managed to estimate more stories this way than would have been the case if we had estimated the usual way.
Moving on to Iteration Planning we had a bunch of proposed Acceptance Tests prepared to define each story. These were discussed by the Whole Team, including the customer. We slightly redefined a few of the stories by changing details in the proposed tests, and also came up with some extra tests needed to prove the function. Along with the definition of Acceptance Tests we also performed the Task Breakdown of each story. Here it seemed that the developers were the only ones really needed though, so in the future we might do that after the Iteration Planning.
Simon, Tommy and Angelina playing Planning Poker
When the customer arrived we first prioritized all the stories we had, including the ones that we didn't have time to estimate. Once the priorities were in place it was a no-brainer to choose what to include in the first iteration. We simply calculated how much time we would be able to spend during the iteration and then selected stories from the top until we reached the available time. The stories with high priority were all estimated by the morning session. We also created a release plan with some set dates for different parts of the project.
Moving on to Iteration Planning we had a bunch of proposed Acceptance Tests prepared to define each story. These were discussed by the Whole Team, including the customer. We slightly redefined a few of the stories by changing details in the proposed tests, and also came up with some extra tests needed to prove the function. Along with the definition of Acceptance Tests we also performed the Task Breakdown of each story. Here it seemed that the developers were the only ones really needed though, so in the future we might do that after the Iteration Planning.
Friday, October 16, 2009
More about writing user stories
In this project we've decided that I, as Interaction Designer, should write the user stories. I've worked in projects where we've used stories for planning our work before, but then we've mostly focused on the size and the independency of the stories. We've also prioritized functions before writing the stories, and writing them have been done by the whole team as a part of the planning activity.
This time we've been writing stories with the mindset to make them, Independent, Negotiable, Valuable, Estimatable, Small and Testable. We've learned these rules from Bill Wake.
An Interaction Designer should be aware of the user value in everything they do, and I find it useful to formulate the user stories so that they express how every part of our project is of value either to the end user or to the customer. In this way everyone in the team will be reminded of why a function should be developed and it will also be a good help to prioritize the stories later.
The writing of user stories in this project has been much about documenting a prototype that we've created in the pre-study. This work has been good because we've once again been forced to challenge everything we've decided to develop with the question "Why would the end user like to have/do this?"
To me the most difficult part of writing the user stories have been to make them independent. We have a step-by-step flow where the user first signs in, then fills in a form, and at last submits the information. Having a story including filling in a form while excluding the submitting part is not an independent story, but including the submitting part may make the story to big. Instead we’ve tried to split that story into several stories where some is about functions that make it possible to fill in the form (e.g. listing and manipulating information), and another one is about actually filling in the information and submitting it.
It has also been hard to make the stories both small and negotiable. Adding too much detail is easy, especially since we already know a lot about details from the pre-study.
Writing stories alone is hard. After a while you come to the point when you do not question your own writings, if you’ve once thought that a story seems to be, for example, negotiable it is difficult to reconsider it without a second persons view of it. Therefore I’ve had a great help from the developers and the Test Manager in my team. Discussing the stories has lead to new, deleted and rewritten stories.
The next step will be to take the user story draft to discuss with our customer!
To learn more about writing user stories I’ve been reading:
This time we've been writing stories with the mindset to make them, Independent, Negotiable, Valuable, Estimatable, Small and Testable. We've learned these rules from Bill Wake.
An Interaction Designer should be aware of the user value in everything they do, and I find it useful to formulate the user stories so that they express how every part of our project is of value either to the end user or to the customer. In this way everyone in the team will be reminded of why a function should be developed and it will also be a good help to prioritize the stories later.
The writing of user stories in this project has been much about documenting a prototype that we've created in the pre-study. This work has been good because we've once again been forced to challenge everything we've decided to develop with the question "Why would the end user like to have/do this?"
To me the most difficult part of writing the user stories have been to make them independent. We have a step-by-step flow where the user first signs in, then fills in a form, and at last submits the information. Having a story including filling in a form while excluding the submitting part is not an independent story, but including the submitting part may make the story to big. Instead we’ve tried to split that story into several stories where some is about functions that make it possible to fill in the form (e.g. listing and manipulating information), and another one is about actually filling in the information and submitting it.
It has also been hard to make the stories both small and negotiable. Adding too much detail is easy, especially since we already know a lot about details from the pre-study.
Writing stories alone is hard. After a while you come to the point when you do not question your own writings, if you’ve once thought that a story seems to be, for example, negotiable it is difficult to reconsider it without a second persons view of it. Therefore I’ve had a great help from the developers and the Test Manager in my team. Discussing the stories has lead to new, deleted and rewritten stories.
The next step will be to take the user story draft to discuss with our customer!
To learn more about writing user stories I’ve been reading:
- The first three chapters in User stories applied by Mike Cohn. I think I learned the most from this reading, I appreciate that it has several describing examples.
- Advantages of the “As a user, I want” user story template from Mike Cohn’ s blog
- User stories at extremeprogramming.org
- User stories at Wikipedia
- A chapter about User stories in Extreme programming explained by Kent Beck. I found this reading quite brief (probably because I read it after all the other reading), but it may be good to get a first idea of what this is about.
Subscribe to:
Posts (Atom)