HTML5: Analyze or generate your favicon

RealFaviconGenerator.net analizes your favicon and tells if it is compatible with major platforms. You can also use it to create a favicon if you don’t have one already. It’s a pretty nifty tool. Check it out at RealFaviconGenerator.net

Scrum Mastering

Note: this is not a comprehensive post, just stuff I picked up during my recent scrum master certification class. Take from it what you will 🙂

What Is It?

Daily standup meeting, maximum of 15 minutes. 7 people per scrum team is the best setup, 10 is iffy. Open space is best for scrum because it keeps people alert and standing means they’ll be paying more attention. Best to do the standup meeting in an empty room.

Product Backlog

Composed of user personas (ie who will use your software, what kind of person are they) ordered from highest importance to lower importance based on who is the largest user base, how much $$ they have, how frequently do they will use it, what kind of social impact do they have, features specific to them and features shared. This is used to help the product owner determine the business value and priority of each user story. These are then taken to the release backlog. This is who the product is for. In the picture below, features are placed horizontally for the user persona they apply to and turned sideways to indicate they are core functionality. These features are turned into user stories. Typically agile teams will tackle core functionality first since it spans multiple user stories.

Sprint Task Board

Kanban board (Japanese work meaning status, graphic). Has three columns, TODO, IN PROGRESS and DONE. TODO section contains the tasks to be completed also known as Sprint Backlog.

User stories are high level concepts that are broken into tasks which can be completed. User stories should be completed in a single sprint.

Tasks are estimated according to time.

User stories are assigned story points according to complexity of the story.

When you’re planning a story/tasks you plan to keep them busy for 70% of their time since the other 30% might be discovering things that you’ve missed.

Decomposing user stories into tasks is done in the sprint planning meeting.

QA testing should be done once the story is done rather than each individual task.

If you have a separate QA team then you need a QA task for each user story. The QA team would estimate the value.

Sprint Burndown Chart

A chart of the progress done over time. It starts with the total number of estimated minutes and drops as time passes.

A typical sprint has little work and then the work is added and then it falls over time. If that’s happening then you’re not planning your sprints properly and you’re not protecting the sprint (ie adding more work) when you should be. In this case you can see the team has a clear planning issue, therefore the curve of the sprint burndown will be more of an downward trend.

When you start achieving complete sprint burndown you might not even need to use this chart anymore. It’s like training wheels on a bike, once you’ve figured it out you won’t need it anymore.

Poorly planned sprint

Correctly planned sprint

Release Burndown Chart

This is a similar concept to the sprint burndown except it’s used with sprints instead of with sprint tasks. By calculating the velocity you can add and remove user stories from the release planning in order to get all the story points done in the year.

Velocity calculations

Velocity calculated over time

Definition of Done

The processes that need to be completed for each User Story are put up on a checklist and then each part is checked off as it’s completed. Once all checkboxes are marked the User Story is considered done.

Sprint Backlog & User Capacity Chart

Setup a user capacity rundown chart to help organize the team and figure out how much capacity you have for the sprint. The picture below shows the sprint taskboard and the sprint backlog. The white piece of paper is the user capacity chart. User capacity starts with 80 hours for the 2 weeks and then goes down if team members will be out/vacation. Then you add some buffer for other stuff they might end up working on or tasks taking longer than expected. Next you start asking who wants to take which tasks and use up the remaining capacity. This will also help you figure out if you can take on more work or have too much work for the sprint. This is how the team plans to accomplish the sprint goals.

Team Calendar

Recommended team calendar setup. Backlog grooming will help you start to plan your user stories for the next sprint. DSM = daily standup meeting.

The Agile Manifesto

Winston Royce invented the waterfall model by documenting what his team was doing during their development process. The core values of the Agile Manifesto are:

Individuals and Interactions – over processes and tools
Working and Software – over comprehensive documentation
Customer Collaboration – over contract negotiation
Responding to Change – over following a plan

The principles behind agile are:

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software
2. Welcome changing requirements, even late in development. Agile process harnesses changes for the customer’s competitive advantage.
3. Deliver working software frequently. from a couple of weeks to a couple of months, with a preference to the shorter timescale
4. Business people and developers must work together daily throughout the project
5. Build projects around motivated individuals. Give them the environment and support they need, and thrust them to get the job done.
6. The most efficient and effective method of conveying info to and within a dev team is face to face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers and users should be able to maintain a constant pace indefinitely
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity — the art of maximizing the amount of work not done — is essential.
11. The best architectures, requirements and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts behavior accordingly

Empirical vs Defined

Defined is something that has architecture and structure, ie a sewing pattern. Empirical is something that isn’t well defined, ie a custom made garment made without a sewing pattern. Software is inherently empirical. The first time you make a feature that you’ve never attempted before you won’t know how long it’s going to take and how much effort it requires therefore you can only provide an estimate. Something that is well defined has been done before therefore you can give a set amount of time and effort to complete the task.

Output vs Outcome

We often focus so much on the output that we forget about the outcome. Producing more code/features doesn’t necessarily mean you’ll have a better outcome. In terms of Agile and Scrum outcome is more important than output.

Product Owners

Agile Is Just That

Since Agile is a set of principals there’s many different ways you can accomplish it. Here’s a look at the Spotify engineering culture which has been using Agile from the beginning. You can quickly see how they’ve deviated from what most people consider the “traditional” ideas.

Scrum Developers

6 people per team, 1 of them is scrum master, is a good idea because it allows them to pair up for pair programming.

Motivating Your Team

Autonomy and mastery and contributing are better motivators than money or bonuses or prizes.

Golden Circle

A. Why you want to create the product (should invoke a vision/feeling)

B. How you’re going to create the product

C. What you’re going to do to create the product backlog

Useful Team Activities

2-Dimensional Axis Chart

X axis is used to denote how much something was successful or unsuccessful (loved it vs hated it). Y axis is used for time. Sticky notes are then added to correspond with the features/activities that occurred. This lets people vote someone anonymously and gives you a feel of what you could work on improving.

Put up the chart

Have people place their votes and analyze results

Planning Poker

Create cards (100, 60, 20, 8, 1) that represent the story points which are tied to the complexity, effort and cost to create the feature. Assign those values to the user stories via vote (majority wins, hear from outliers and re-vote after). Adding all of those up will give you the total user story points for that release.

Dot Chart

Take the items you can improve from the previous chart and put them on a new graph. Now have people come up and put a dot next to those they feel most passionately about, a larger dot indicates they feel more strongly about it. This will help you identify the areas where the majority agrees there is room for improvement. Sorry it’s blurry.

After a Team commits to sprint goals what authority do they have?

The team does whatever is necessary to achieve the goal.

How are development teams guided during a sprint?

By their collective knowledge and experience.

From Product Vision to Your First Sprint

1. Create the product backlog from the golden circle design
2. Create the user personas
3. Create the user stories (product backlog)
4. Move the stories into the release backlog
5. Move the stories into the different sprints
6. Create tickets for the sprints
7. Move the user stories from the release backlog into the sprint task board when your release backlog is done being planned.
8. Now create 7-10 tasks for the user story
9. Discover any dependencies between the tasks
10. Now we have to estimate how long it takes to complete the task using 8, 4, 2 and 1 hours (finger voting). Any task that everyone votes for an 8 is too complex and needs to be split into additional tasks. User stories should be completed in under a week, if your user stories are indicating more than 40 hours then you need to split them up.
11. Once you have the sprints planned it’s time for capacity analysis.
    1. For someone with an 80 hour sprint you should expect that they only have 55 hours of actual work time — this accounts for buffer time.

 

 

 

 

Protect Apache web-server from application DoS attacks (Ubuntu)

Good stuff.