Story points cannot be converted to time. Deadline commitments are part of waterfall, not agile.

Agile development focuses on short iterations to boost development speed. This is related to project management.

Agile development is strongly related to or overlapping with methodologies like lean manufacturing, Poka-yoke, Kanban, Six Sigma and Scrum.

Pure agile methods rarely fit to an organization. Two companies can have totally different development process even they both state that they use Kanban. Agile is just an approach of doing things, the way you do it is up to you

All agile practices are different variants of Plan-Build-Measure-loop. Aim is to construct working software as fast as possible and improve it in short-term iterations. This allows getting faster feedback and validation from the end-users.

Plan-Build-Measure-loops are usually implemented as:

• Plan is made from stakeholder requirements, customer feedback and problem domain expert insights.
• Building is done by programmers, designers, artists and problem domain experts. Aim is to have a working product after each build phase.
• Measuring is done by a quality assurance team and the end-users.
• Then you start again from planning, relying on the measured feedback.

Be transparent. Agile practices can easily become ultimate tool of micromanagement. Monitoring people as they work is really demotivating, you should only focus on the results.

Let's have Jira so we can monitor you! THAT IS TRANSPARENCY!

Simplified Scrum

Simplified Scrum is a good starting point to get into agile development with a smaller team. First you make a 3-10 person team and...

1. Decide a time period you are going to work for.
2. On the first day, plan what to get done in the time period.
3. You should have a briefing with the development team every day.
4. After the time period, you review did you go according to the plan.
5. Release and repeat.

Time Period

Time period should be between one and two weeks. The smaller the iteration time is, the more efficient it will be. It all depends can you be disciplined enough to release weekly.

Big companies are more sluggish. Having short iterations is usually hard in big companies because of all the bureaucracy and other overhead you need to consider.

Plan

Decide what you are going to get done in this time period. Always consider removing excess features and focusing on the core features. Avoid adding features. Prefer merging, extending and automating features. Always fix bugs before writing new features.

1. Estimate how much each possible task would add business value.
2. Roughly estimate how much time each task would take to complete.
3. Compare these two qualities and prioritize the ones are relatively fast and add the most value.

Everyone can estimate, but no one can estimate perfectly. Giving accurate development estimates is fundamentally impossible, so avoid wasting time on estimating but still make rough estimates. More about estimates in development estimate notes.

Avoid using values to speculate required effort. You might have few priority levels like "important" or "secondary" but keep it in line. Estimates are important, imaginary effort value is not.

All tasks are assigned to specific people in the development team. Team members then split their own tasks to chunks of work that do not break the whole system. You can always get to under one day chunks. Finally team starts working on tasks.

Briefing

Daily briefings are status checks for reaching your goal you set on the planning. Each team member tells:

• What they did yesterday?
• What they are working on today?
• What is slowing them down? Mention even the small things.
• Can they meet the time period deadline?

Daily briefings should take less than 15 minutes. Meeting should be done while standing up so you can notice when people notice more easily that it goes overtime.

Not everyone needs to be present every day. If one person is missing, just keep the meeting anyway.

If someone cannot meet the deadline, discuss what to leave out. Also allows redistributing work load to other members if someone has time to make them.

Product owner and scrum master should not attend dailies. It will reduce honesty of reporting possible issues and can easily steer discussion to non-technical details.

You may optionally have email briefings:

• Members sends the team lead an email with title YYYY-MM-DD Briefing.
• They write and send it when they start working.
• Team lead collects all of those and sends collection to everyone.
• Collection is stored somewhere where everyone can access it later.

Review

Each iteration should improve overall quality of the product and the process. Discuss how to make the next iteration work better than this iteration. More product functionality is not necessarily quality.

If someone did not get everything done, talk about why not. Do not blame the person, blame the process and try to fix the process.

Did the member take too many tasks? Give him less tasks in next time period.

Did something unexpected slowed the progress? Expect it to happen in the next time period.

Terminology

You should give names to all these steps so people can talk about them more easily.

// Scrum Time Period = sprint First Day Planning = sprint planning Full List of Tasks = backlog Daily Meeting = scrum Review = sprint review

You can consider theming your naming, just to make it more personal.

Time Period = chant Planning = charting Full List of Tasks = necronomicon Daily Meeting = ritual Review = postmorten

Tasks Types

You should categorize your tasks to separate types:

• Story: a story about what should be possible to do with the program. Stories are split into smaller tasks.
• Epic: a big story that is split into smaller stories.
• Bug: functionality that does not work like it should in some context.
• Improvement: new functionality or significant improvement of an old functionality.
• Sub-task: a thing that must be done but does not fit other categories e.g. planning, meetings, project management.

Sources

• Poor Man's Agile
• Agile FAQs
• Agile Day 2013, No Estimates, Vasco Duarte