Customer: Addestino

Production: Boulevart

Design & concept: Addestino

Technologies used: Flex, xHTML, Flash, Django

Visit: http://www.battleoftalents.be/

The Scrum Team has to make very serious commitment to complete the work (Potentially shippable Product) which requires careful thought to be successful.

Steps for successful estimation:

Estimate Team’s Time available for Scrum:

Estimating the time of each and every team member available for the sprint is very much important as a part of the sprint planning. When a team member estimates a given task can be completed within 8 hours which does not mean he can complete the task in one day. The fact is that no one will seat in one place to do complete the job without attending meetings, lunch breaks, unexpected breaks, checking emails and phone calls etc.

Those who just started practicing scrum will have question regarding “Managing time for bug fixes”. Again we cannot make two sprints one for product backlog and one for bug fixes. The time for bug fixes should be addressed form the daily time available time. It means apart from daily routine work like emails, phones, breaks , you should also allocate some time for bug fixes and the remaining time you can commit for the sprint.

1. Estimate how much time each member can spend for sprint related work.

Available time for Sprint Related work = Average work day time – Time allocated for other activities.
Average work day time = e.g. 10 hours
Time Allocated for other activities: = e.g. 6 hours
Emails and Phone : 1 Hrs
Lunch : 1 Hrs
Reading Blogs : 1 Hrs
Meetings : 2 Hrs
Bug fixes : 1 hrs
Available time for Sprint Related work = 4 hours

Estimate Effort for Each Prioritized Item on the Product Backlog by means of planning poker:

Estimates can be better done by the people who have the experience of similar kind of work already done, Peers and Historical data. It is always better to involve the people who have similar work experience for appropriate estimations.

No one will estimate perfectly for the first time, for sure team members will either over estimate or under estimate the task work, but it makes them realize how much they can produce and for next sprint the team members will try to estimate a bit more precisely.

After three to four sprints, team members will be in a position to understand their own strength and how much work they can do. This leads for better estimates.

2. All the team members must participate in the estimation game (planning poker)

3. Take the prioritized Item from Product Back Log, Understand it thoroughly, what is supposed to be done, any dependencies, complexity, Risk involved, etc. ,. If required get the clarification from the product manager (Pre- Planning).

4. Divide the Prioritized/Understood Item and break it down to individual tasks.

5. Use Planning poker for estimating duration for individual tasks.

a. All the team members must have cards: ½,1,2,3,5,8,13,20,40, 100, ?, Coffeecup
b. Scrum Master reads description of the backlog Item.
c. Everyone selects and simultaneously shows cards
d. If estimates vary significantly, high and low estimators briefly explain why they have estimated so.
e. Repeat steps 3-5 until estimates stop converging.
f. Decide estimate for backlog item
g. Move to next backlog item.

Points to be consider for estimations:

1. Once committed to the sprint work, Team members should not be disturbed by adding additional work or different work then assigned to the team members.

2. Remaining work should be carry forwarded to the next sprint (This happens generally due to underestimates) .

3. Teams must be self organized and have transparency among the team members for achieving the goal.

Follow Scrum Rules to Make your Product Development Successful:

1. Full-Time Product Owner (with Expertise and Authority) Identified
2. Product Owner Works With Team and All Other Stakeholders
3. Product Backlog Created and Managed by Product Owner
4. Daily Scrum Meeting with 3 Questions (Completed? Will Complete? Obstacles?)
5. Daily Scrum Meeting Same Place and Time and Less Than 15 Minutes
6. Regular Sprint Length (no more than 30 days)
7. Sprint Planning Meeting to Create Sprint Backlog of Estimated Tasks
8. Sprint Burndown Chart
9. Team Room with All Needed Equipment and Supplies
10. Retrospective Meeting for Process Improvements
11. Definition of “Done”
12. Commitment Velocity Calculated (from Sprint Backlog Estimates)
13. Team Size (min 2, max 12)
14. Cross-Functional Team Including ScrumMaster and Product Owner
15. Team Self-Organization – Team Members Volunteer for Tasks
16. ScrumMaster Tracking and Removing Obstacles
17. Team Safety – No Interruptions to Team’s Work During Sprints
18. No “Break” Between Sprints
19. Sustainable Pace – Timebox Effort, Not Just Schedule
20. Quality is Not Negotiable – Defects Go on Top of Product Backlog

Summary:

Team understands the details of what the Product Owner has prioritized on the product backlog in the Sprint Pre Planning Meeting:, Team decides how much productive time it has available during the sprint, Team decides how many Product Backlog items it can commit to complete during the Sprint. , And finally team delivers potentially shippable product at the end of every sprint.

References:

1. http://www.scrumprimer.com/scrumprimer.pdf
2. Memories of ScrumMaster Training by Pete Deemer
3. http://www.agileadvice.com/archives/2007/05/scrum_rules.html

Question: What is a Product or Project Backlog?

Answer: A product or a project backlog is a prioritized list of requirements with a rough size and complexity estimate of each requirement. Hence, the backlog has 3 components: requirements, priority, rough size and complexity estimate.

Question: Who provides the requirements in Product or Project Backlog?

Answer: It is typically the role of a product owner or a customer to provide the requirements. However, sometimes analysts from the development team can work with product owner or customer to define the requirements. The idea is for the product owner or customer to work with the team to discuss the requirements during the sprint planning meeting.

Question: How are the requirements written?

Answer: There is no standard way to write the requirements. One team can simply write “users sign in” and another could write “users should be able to sign in with their email address and password”.

Question: Is additional information captured in the requirements?

Answer: Yes and no. It depends on project to project and requirement to requirement. Something like Forgot Password might not need further information but something like User Registration might have various notes on each field like date of birth (should be 13 or more) and password (strength).

Question: Do we require “acceptance tests” for the requirements?

Answer: Yes, highly recommended. However, having acceptance tests for all requirements would be too time consuming. Also, the team and product owner or customer should discuss the acceptance tests for each requirement in detail during the sprint planning meeting. It is useful to remember that Scrum is collaborative and both the customer or product owner and team should discuss and agree on “definition of done” before the start of a sprint.

Question: Do we need details on everything for each requirement on the backlog?

Answer: This is not really required, although nothing stops you from going this route. However, the closer the requirements are placed to the current sprint, the better they should be defined.

Question: Do we need to estimate each requirement in the backlog?

Answer: Yes, it is recommended that each requirement be estimated. The requirements far from the current sprint can only be coarse grained and hence roughly estimated. However, this gives product owner or customer a rough idea of the project size and number of sprints required to complete a project. The final number of sprints could be more or less, but at each stage the visibility of progress would be self evident.

Question: How is the estimate done – in days or in hours?

Answer: You could use either, although relative estimation would work better. The team and product owner get together at sprint planning meeting. They pick up the simplest requirement from the list and arbitrarily assign a number to the same [say 1 or 1 requirement point or better still 1 coffee cup]. All other requirements are estimated in similar units [requirement points or coffee cups]. At the end you total up the points. At first the team could take a guess at the amount of points it could complete in a sprint. After a few sprints, they would have visibility of how many points they should ideally take. This estimation technique works well to give you rough idea of work that can be picked up. Its not supposed to be used for precise calculations or a point in horizon rather just aim for a region in horizon.

Question: How do we estimate – based on size or complexity?

Answer: The short answer to that is both! Entering 1000 records in database might not be complex, but time consuming and on the other hand investigate SOA performance issues in reports in a clustered environment may be complex and hence, difficult to even give a precise estimate on. And in some cases, you might want to factor in both. Hence, you estimate both from difficulty level as well as effort required.

Question: How is the backlog prioritized?

Answer: It is the responsibility of product owner or customer to prioritize the backlog. The team can provide assistance in the same though. The backlog is prioritized by means of MoSCoW prioritisation (Must Have, Should Have, Could Have, Won’t have this time) together with business value.

Question: Does the backlog provide any tracking?

Answer: Yes, you can make a simple tracking of completed/ pending items. You can also track number of requirement points completed in a sprint and based on average requirement points completed in a sprint and total requirement points pending, you can get an idea of the projected completion date. The average requirement points completed in a sprint is also called velocity.

Question: Is there a low level tracking involved?

Answer: Yes, you can divide each requirement into tasks. Each task can be estimated in number of hours it would take to complete. This is typically done only for a given sprint and is called a sprint backlog and is maintained separately from product or project backlog.

Question: Is the product or project backlog only made once – at the start of a project?

Answer: No! There are only two rules. First,the product or project backlog should be revised and continuously updated based on emergent scenarios and situation. Second, the backlog for the sprint currently in progress can’t be changed. The backlog for upcoming sprints can be changed almost completely. In a fixed price scenario, this might mean you need to swap new functionality with existing functionality.

• Screen looks superb
• The application response is really fast
• Touch foil gives good response through our 10 mm plexi cover.
• Low hardware requirements.

Our project goal was to create a fun application which could elaborate the screen’s full potential.

The puzzle created by Boulevart makes good use of the touch technology. It would be much slower to operate with a traditional mouse.

Hardware
Case design by Joris Vanbriel from Holocube.
Joris and Jan Vanbriel did a great job solving all the hardware issues.
Current prototype uses a 46” plasma with a built-in Mac Mini. Final project will use a Mini-Itx with IDE flash memory to save space and provide a faster startup.

Software
The application is built on WPF technology which suits perfectly for the job.
WPF does great on spreading the appliction load onto multiple CPU cores and can use GPU hardware acceleration.

Playing these 1360 * 720 fullscreen videos results in 30% CPU load on a 1.7 Ghz dual core setup.
Realtime video slicing using WPF’s Visualbrush.

Movie and demo by Arne Jennard

1. The team is empowered to make decisions.
2. The team is self-organising and does not rely on management to set and meet its goals.
3. The team commits and takes responsibility for delivery and is prepared to help with any task that helps the team to achieve its goal.
4. The team knows who the product owner is.
5. Each sprint/iteration has a clear goal.
6. All team members, including testers, are included in requirements workshops.
7. Requirements documentation is barely sufficient and the team collaborates to clarify details as features are ready for development.
8. Test cases are written up-front with the requirements/user story.
9. There is a product backlog/feature list prioritised by business value.
10. The product backlog has estimates created by the team.
11. The team knows what their velocity is.
12. Velocity is used to gauge how many user stories should be included in each sprint/iteration.
13. Sprints/iterations are timeboxed to four weeks or less.
14. Sprint budget is calculated to determine how many product backlog items/features can be included in the sprint/iteration.
15. The sprint/iteration ends on the agreed end date.
16. All tasks on the sprint backlog are broken down to a size that is less than one day.
17. Requirements are expressed as user stories and written on a card.
18. The team estimates using points which indicate the relative size of each feature on the product backlog/feature list.
19. The team generates burndown charts to track progress daily.
20. Software is tested and working at the end of each sprint/iteration.
21. The team is not disrupted during the sprint/iteration.
22. Changes are integrated throughout the sprint/iteration.
23. Automated unit testing is implemented where appropriate.
24. There is an automated build and regression test.
25. Stretch tasks are identified for inclusion in the sprint/iteration if it goes better than expected.
26. The Product Owner is actively involved throughout each sprint.
27. All code changes are reversible and it is possible to make a release at any time.
28. Testing is integrated throughout the lifecycle and starts on delivery of the first feature.
29. Impediments that hold up progress are raised, recorded on the whiteboard and resolved in a timely fashion.
30. When someone says ‘done’, they mean DONE! (ie shippable).
31. The team uses the whiteboard to provide clear visibility of progress and issues on a daily basis.
32. The sprint/iteration goal(s) is clearly visible on the board.
33. All user stories and tasks are displayed on the whiteboard for the duration of the sprint/iteration.
34. Daily scrums happen at the same time every day – even if the scrum master isn’t present.
35. The daily scrum is resticted to answering the standard 3 scrum questions and lasts no more than 15 minutes.
36. There is a product demonstration/sprint review meeting at the end of each sprint/iteration.
37. All team members, including testers and Product Owner, are included in the sprint/iteration review.
38. The sprint/iteration review is attended by executive stakeholders.
39. There is a sprint retrospective at the end of each sprint/iteration.
40. Key metrics are reviewed and captured during each sprint retrospective.
41. All team members, including testers, are included in the sprint retrospective meeting.
42. Actions from the sprint retrospective have a positive impact on the next sprint/iteration.

They score 42 of course!

“As a role, I want something so that some value“. The template is burned into your brain. “I always use that template!” I hear you proudly say. “See? Here’s an example: As a user, I want a glass of lemonade so that I drink something.” Ok, stop right there. I know that the world of software development changes rapidly, and there’s just so much to keep track of. But maybe it’s time to revisit some of those foundational practices you take for granted. No, of course you are doing it right. We just want to make sure the new guy over there understands. In today’s timely reminder, let’s revisit on how we write user stories.

Like most agile practices, it’s not good enough to just do the practice -you have to do the practice in the spirit in which it is intended. That way, you can evolve it to better help you achieve the goals it is meant to help you reach.

So what’s the goal of the user story template? Well, a lot of smart folks have written about this. That’s why this is a timely reminder and not a timely revelation. But to me, it’s about capturing system behaviors that have business value. To get there, it asks 3 questions:

1. Who?
2. Does what?
3. And why?

Let’s re-visit the user story for our killer Lemonade Stand app:

As a user I want a glass of lemonade so that I drink something.

Who?

A “user”, that’s who. I consider “As a user” to be a story smell. Every so often, it’s actually appropriate, but most of the time, it’s not. The next time you catch yourself writing, “As a user”, stop and think about who this user really is. In our case, maybe this user is a charitable neighbor. Or maybe she’s a lemonade connoisseur. Or maybe she’s a gardener who’s been out in the hot sun for hours and is overheated and incredibly thirsty.

Why does it matter? Well, I find that frequently, when I start identifying who the users really are, I gain insight into workflows these stories are a part of, and I figure out how to optimize their experience using my software. So with the charitable neighbor, I may not have to worry about the quality of my lemonade as much as with the lemonade connoisseur. And if my user is the overheated gardener then maybe I need to start thinking about glass sizes. Then again, maybe identifying the user doesn’t change the story. In that case, I still think it’s valuable because now I’ve at least asked that question and had that conversation instead of avoiding it.

Does what?

Wants a glass of lemonade. This is the part that most people get right -sort of. The problem is that we love features, don’t we? But it’s not really the features we care about, it’s the behaviors -we just think it’s the features. In everyday life, the features we want often have the action implied. When I say that I want a new piano, you can safely assume that I mean that I want to buy a new piano. Sometimes it’s obvious in software and sometimes it isn’t. When in doubt, make the action explicit.

In our example, “As a charitable neighbor, I want a glass of lemonade…” might be ok. But I would still add the action because it could be either “to buy” or “to drink”. Both could be right, but may lead to different conversations and outcomes.

In particular, watch out for the product manager forcing a feature she wants into a story and tagging it with “As a user”. Because all users must be clamoring for this magical, out-of context feature, right?

And why?

So that I drink something. Because I like to randomly drink things, don’t you? This is where we state the case for the value this user gets out of performing this action. I can’t tell you how many times I’ve been certain I needed a feature in a hobby project, went through the act of writing the story anyway…

…and ended up throwing the story out because when I got to the “so that”, I realized it had no real value. I’ve seen this happen on professional projects, too. Another common occurrence is when, in clarifying the value, we realize that the behavior we want needs to be adjusted.

The above demo was done on a MSI windtop touchscreen (dual core 1.5Ghz Atom CPU)

Download the Application
Use M to (de)activate the mouse.
Use F to toggle fullscreen.
Use ESC to exit the application.

Crossposted on: Lab101

Customer: Aspria London

Production: Boulevart

Design & concept: Boulevart & Pool World Wide

Technologies used: Umbraco, xHTML, Adobe Flash

Visit: http://www.aspria.de/de

Customer: Akzo Nobel – (fore)sé

Production: Boulevart

Design & concept: Boulevart & Pool World Wide

Technologies used: Adobe Flash, 3D studio MAX, After effects

Visit: offline presentation