Great post Stephen! Would you mind going into more detail on the concept of "Scrum Poker" and how it would allow me to take you to the cleaners? ;-)

So in brief, planning poker is a fun way to estimate out the different user stories in the planning phase and give them some relative meaning. Usually each team member is given a handful of cards with numbers on them (e.g. 1,3,5,8,13,20,40) . The numbers and range of cards all depends on how diverse you want the estimates.

At the start of each User Story the Product Owner reads the description of that User Story and the team then has a chance to ask questions on it, to determine how difficult in their opinion the story is. Once all questions are answered the individual team members then vote using their cards. Note, cards are not shown until each estimator makes a selection to stop people getting influenced by other members of the team. The cards are then turned over simultaneously.

If the votes differ dramatically then a discussion is had with the high's and low's to learn about why the vote was cast that way. After that a 2nd round can happen where people vote again. cont.....

cont... Lastly, once all the User Stories are estimated, the Product Owner can then priortize the list of User Stories to be done in a Sprint.

I dont want to take up too much space here. Hope that helps..

In my previous company it was and is still a very complicated process if you have to coordinate dependent task between multiple scrum teams. Also a scrum of scrum meeting is not always the best solutions. As long not the whole company works the scrum way of life it can be a very painful experience. In my new company it works much better now. Also because of the fact that our team is much smaller and we have everyone necessary for the project in one team. For all all the reporting, backlog mantainance, velocity calculations and so on I can highly recommend pivotaltracker. It´s one of the best tools around in my opinion and it´s 100% free -> www.pivotaltracker.com

Christoph,

Thank you for your contribution. I think you brought up a very important point when it comes to executing SCRUM successfully in a professional environment.

Introducing SCRUM within a company requires much more than simply establishing the process and methodologies of the SCRUM framework. What I consider key for any Agile methodology to succeed is to have your team as well as any relevant stakeholder thinking the Agile way and fully comitting to its core principles. We at Fi foster the Agile mind set by holding work shops internally in which we educate our team about the Agile principles and in particular the SCRUM framework.

Thanks for your tooling tip - we will definitely take a look! As mentioned in the entry, we are currently using Rally's Community version but have tried other services before such as e.g. ScrumWorks or VersionOne. Would be interesting to hear from other Kontain users what Agile (or even non-Agile) project management tools they prefer.

Wow, I like this concept of short listing the User stories. We usually create based on BRD & User personas, but have never rated it like this before, need to try this concept. Can you share us how does the Usability guys in Fi are creating the actual screens, are they evolving out after series of iteration from Mockup screens which is created based on user stories or do you follow some other process.

I 100% agree with Christoph's shout out to Pivotal Tracker, we currently use it at The Barbarian Group on a number of large projects as well, and after trying out a few other platforms for this intended use, we found it to be the most robust AND user friendly to the client and ourselves. Highly recommend.

As a designer working within SCRUM, I'm personally interested in what you guys have found to work best for people not on the dev team. This process works magically for developers, and we've tweaked a few of our processes as designers to better fit into a day-by-day iterative model, but I'm sure there is room for improvement. Care to share any thoughts on this? I didn't notice any mention of designers up in the post, so I'm curious.

Good work Stevo!

I am so glad to hear that Fi is using SCRUM, I was studying this methodology and I wanted to know who was using it. I tried traditional methodologies before (PMI) but there is no way to apply it for web projects. SCRUM is all about a new way of thinking and working, the most important thing is to educate the team about it. Do you use only software or physical post-its too?

We use www.myintervals.com instead of basecamp, I think it is much better, you have all kinds of reports, by person, worktype, how many hours was spent in each project, costs, etc.

That’s a good question and something that depends on the size and complexity of your team. At Fi we tend to have more technical members in a team at one time than designers and IA people. So there needs to be a split on how we approach the sprints and releases. The aim is to always make sure the design team is ahead of the development team working on a list of prioritized items. Having these small group work on an Agile system is not always efficient, so we utilize tools such as Basecamp for smaller groups and take some of the key features of SCRUM to keep the process as Agile as possible.

I hope I understood your question correctly.

Hi Anthony, I think this is similar to what is been asked in the previous comment about the different teams. As I mentioned, the ratio of the design team to the development team is usually significant enough to not follow a strict Agile approach using all the methods mentioned in the entry above. The Key idea is trying to implement a hybrid approach of taking some of the key principals of the methodology and applying them to the design team on the same project. For example there can be

• Scrum Meetings

• Estimated and Prioritized task

• Demos

The design team usually have a harder time estimating the work due to the creative effort that goes into designing and conceptualizing a component or page. So there is definitely some work to do in keeping the design team on track and ahead of the development team. This is an area where we are constantly trying to improve to figure out the best balance between having a team split up into different disciplines working towards the same goal.

@Anthony, I would be interested in hearing how you deal with this challeneg in your work place.

We use both. Recently we started to put items physically on the wall for the team to interact with. They are

• Burn Down Chart

• Parking Lot

Burn Down Chart

We have a burn down chart in our software tool, but that gets lost very quickly. Myself and Thomas decided it would be cool to put it up on the wall on big paper and the Scrum Master draws the progress everyday with the team. That gives a lot more transparency for the team on a daily basis if they are on track or not.

Parking Lot

We also have a parking lot on the wall. This is a simple concept where any of the team can write a question on a post-it and stick it up in the parking lot. At the end of every scrum we take a look at the parking lot and make sure we are acknowledging all of the questions and hopefully removing them.

I suggest a good balance between the digital world and the paper world to help your team understand and appreciate the approach.

This time with my kontain account (aka Christoph Atteneder). We also use physical post-its on a board for our current sprint. We put up our user stories and the corresponding tasks. Digitally we only keep track of our stories, because that´s what has an end user effect. During our scrum meetings before every iteration we split up the stories if necessary into tasks, which shouldn´t take longer than a day - So it´s more motivating if you can (or should ;-) ) move one post-it every day into the done area. The physical Parking Lot and the Burn Down Chart are definitly a good idea, although the Stories Burn Down Chart doesn´t change that much until the last few days ;-).

@Platago: Thanks for your interesting insight into your SCRUM processes.

I would be interested in hearing from you or other SCRUM practicians here on Kontain what your approach is regarding the actual dimension used for estimating the effort of user stories. We at Fi prefer estimating in ideal hours versus using an abstract complexity metric as often motivated in the SCRUM theory.

[continuation next comment]

Estimating in ideal hours has the benefits of

• Working with a metric that is relatable to all stakeholders compared to a complexity metric that only has a semantic meaning within your SCRUM team

• In combination with tracking actuals (=the actual effort for the completion of a user story), using ideal hours allows for a direct feedback loop for each SCRUM team member how good the initial estimate was which in the long run improves the quality of your team's estimate

• Allows for an easier integration of new team members during a project into the estimation process (when using a complexity number new team members will first have to first get educated what different complexity values actually relate to you by looking at earlier estimated user stories)

Looking forward to hearing your thoughts!

Great post guys. Thx for the insight!

Nice work on all of your Scrum practices! I think the Scrum Alliance would hold you up as a poster child for Scrum! I noticed that you said it has been 2 years since you started using Scrum. That takes a LOT of organizational commitment and patience. When I teach CSM classes, I tell groups that to have real Scrum fully adopted in an organization, you can look to a 2 year adoption. We've been doing Agile at Rally for 6 years and we STILL keep changing and adapting. The good news is that we now are fully agile THROUGHOUT the entire company. Every group runs in iterations, has daily standups, makes commitments, prioiritizes their work, etc. Are you seeing this at Fi? I have found that when I coach other organizations, they get very interested in getting Agile to scale up and out into the rest of the organization. Everyone then understands timeboxes, commitments, priorities, frequent delivery, and the value they bring to ALL, not just Engineering. Thanks again, and congratulations! Jean

*blink* *blink* Do I need to learn this?

In my former company we started our estimations using ideal hours in the beginning because we thought it would be easier for our stakeholder (who aren´t working agile bye the way) to have a feeling what this estimation means for them. This metric ended up in a situation that our stakeholders started planing on their side automatically with our first estimations and were more than frustrated that we didn´t reached our commitment at all. So my devs started giving safety estimations (dev thinks it takes two hours but estimates 4 hours just to be sure he will be able to finish it). In the end everyone was afraid to estimate, it ended in weekend and nightshifts because of our commitment and it wasn´t very satisfying for both sides. I think using abstract metrics takes away the pressure of the developers, because the stakeholders have no idea what this metric means and they have to wait a view sprints until there is a realistic velocity you can plan with. So now I´ve run out of available chara...

I am really lost, What is this topic aiming towards at ? and What is it related to ? I'm so confused !

Yup, thanks for clairifying me.

@Stevo: We definitely don't use the official SCRUM practice as designers, but as you mentioned, we use the key points from it. The designers at my company tend to do the following: at the beginning of the sprint, we decide what tasks we shall take on and MUST finish and present by the end of the 2 week sprint. After deciding our tasks we estimate using an 8-point scale (within Pivotal Tracker.) At times it can be frusterating and at first it was rather odd and foriegn, but I've been on a project for about 14 months now that uses SCRUM and I've found that as a designer, it's allowed me to streamline my workflow tremendously and to focus the tasks I am working on to a specified list, rather than hopping from on comp to another should I grow tired of designing buttons one day and feel the need to design some form elements or whatnot.

It's definitely a useful tool, but from a designer, it's definitely also an odd thing to get used to at first. I definitely still highly recommend it though

d

random question, on your guy's web site you have some awesome lighting effects and shadows. Do you use a photoshop plugin for that?

Hey Carl. Any particular part of the Fi site you can refer to? No plug-ins though to create shadows and lightning effects. They're all by hand ;)

http://f-i.com/work/ur/ursmart

if you look at the images they have some sweet shadows. I tried making some shadows using layers and feathering but they had strobe / line effect. How do you get them so smooth? Thanks for the help!

If you mean the grey "surface shadows" underneath objects, there's a bunch of ways doing them. The easiest way (but not that dynamic if you want to re-use the same shadow on different objects) is to fill a circle with black. Transform it so you sort of squeeze it flat, add the transparency strength you feel match the best. Add some gaussian blur, a little bit of horizontal motion blur and... BOM! There you go! Easy peasy!

Or do you mean the reflection in the big top image?

How do you use Basecamp to manage your projects?

I use Basecamp + a post-it taskboard for that day's stories and tasks.

Hi, 3 months after reading this most valuable post. We at pocketpixel just recently decided to use scrum for one of our main projects. Now I've got a question which is how does Fi seat your designers and developers within the scrum team? Together or separately? thanks!

Hey Aidil, awesome to hear you are going to give it a try. As far as seating we usually try and keep the teams as close together as possible without causing too much movement. There is always something that can be solved much quicker when a designer raises an issue to the developer close by. It also gives more of that 'team' feeling. If a designer is isolated in a design team away from the core scrum team that can work, but can also lead to communication issues depending on the complexity of the project.

So my 2 cents is to try keep your core team as close as possible...Hope that helps.

There is also another discussion going on over here about a Producer's tool belt and Producer job opportunities at Kontain and Fi