Category: Project management

Key meetings when doing agile projects

Jan Schwaner
Facebooktwitterredditpinterestlinkedintumblrmail

There are a number of key meetings that should always be included in an agile development project. Some of these meetings will seem familiar to those of you who know the SCRUM framework. However, SCRUM only covers the part that involves the development team and their progress, it doesn’t really support keeping your stakeholders informed about process, budgets, timetables etc.

The sprint startup meeting
Purpose: Define and describe
Duration: Between 2 hours and a day.
Participants: Everyone in the SCRUM team and the Product Owner.
Results: Every user story is described, understood by all team members and broken down into subtasks of no more than 4 hour to 6 hours.
Every time you start a sprint, you should schedule a sprint startup meeting. This meeting will define, analyze, specify and describe all the work that is to be done in the coming sprint.
Questions from the developers can be answered by the product owner and everyone will know what will be done and how it will be done during the next sprint.

Daily stand up
Purpose: Questions, answers and progress
Duration: No more than 15 to 20 minutes
Participants: Everyone in the SCRUM team.
Results: Every member of the team explains what they are working on and how they are implementing it, so coordination between team members is ensured, and also, team members can ask for help or input of needed. In this way everybody can help each other out and the product owner/project manager will get a great insight in the progress of the development.

Sprint retro meetings
Purpose: Evaluation of the teams cooperation in the last sprint.
Duration: Between 2 hours and 3 hours.
Participants: Everyone in the SCRUM team.
Result: The retro meeting will allow for team members to discuss how the work can be optimized, if some parts of the development process could be optimized etc. Each team member should bring at least one topic they would like to discuss and at the end of the meeting each team member will have two votes, which are placed on each item discussed. The two topics with the highest votes will be in focus in the upcoming sprint.

Sterring committee meetings
Purpose: Communicate to stakeholders
Duration: 1 to 2 hours depending on the project.
Participants: Project manager/Product manager or Owner and steering committee.
Results: Approval of the projects progress and expected budget. Approval of changes to deadlines and milestones. Decision on questions that cannot be made by the project manager or project team.
You can read more about how to report to your steering committee in this article.

What makes a great user story

Jan Schwaner
Facebooktwitterredditpinterestlinkedintumblrmail

User storyUser stories are a great way to describe what a future system or solution should be able to handle, and they are great to span the communication gap between UX-designers (user experience designers) and the developers.

User stories are bundled in what is called epics and are broken down into sub tasks.

The user story format.

The user story should always be written using a specific “formula” or syntax. The format is as follows:

As who, I want to what, so that why.

If a user story is put in this format, you are sure to give developers a good insight into what is really wanted and you will make sure that they don’t start doing a lot of guessing once they start developing.

Just compare the two following user demands for a musical festival website. The two demands basically ask for the same thing but one demand is written as a user stories and the other isn’t.
Demand 1: “You should be able to print directly from the website”.
Demand 2: “As a festival visitor, I want to be able to print the musical program, so that I can mark the bands I want to hear”.

The first demand is very open – What should be printable? Is it the tickets or a plan of the festival grounds and maybe we should include the entire website menu? Maybe it is the address of the festival office that is important or a receipt for the purchase of the tickets?

Let us say that “Demand 1” is written 3 months prior to it being implemented and then believe me – No one can remember what “print” was meant to cover (not even the customer).

The user story answers all these questions – We know exactly what is to be printed in what format and by whom. AND it is all documented, so if several months passes before we start implementing, then we will still know exactly what we wanted when we did the user story.

The flow in creating a great user story.

There are three steps and three different focus groups which needs to give input if you want to have a great user story and if you want to create a good flow once the development starts. These groups are the future users, UX designers and the solution developers.

The short version is that the future users put their demands in epics, the UX-designers will break these epics down into user stories and the developers will break down the user stories into sub tasks which they will start implementing.

An example:
Let us say that the users create an epic called “Login”, which they describe as follows “The website should support logins, so that classified information can be shared with employees of the company while they are on the road”.

This epic is then broken down into one or more user stories saying:

  1. As an employee, I want to register as a user, so that I can login.
  2. As an employee, I want to login, so that I may access the classified information.
  3. As an employee, I want to be able to reset my password, so that I can get a new one if I forget the old one.
  4. As an administrator I want to be able to delete a user, so that I can make sure they can no longer access the files when they leave the company.

And so on…

The user stories are handed over to the developers who will then break them down into subtasks of no more than a day’s length. This could look something like this;

  1. “As an employee, I want to be registered as a user, so I can login”:
    1. Create login form including username and password,
      Estimate: 0.5 day.
    2. Create userdatabase tables,
      Estimate: 0.5 days.
    3. Set up MySQL database,
      Estimate: 1 day.
    4. Setup certificate for HTTPS,
      Estimate: 0.5 days.
    5. Order certificate for HTTPS,
      Estimate: 1 hour.

Once the breakdown into sub tasks is done, you simply add up the time expected for implementing the user story, which in this case would be 2.5 days and 1 hour.

The same pattern is repeated for all user stories related to the epic “login”, and the entire budget for implementing the epic is presented to the customer/product owner for approval.

A little tip – Use “accept criteria’s”

A little tip – When doing the user story, you should put in about five accept criteria’s related to the user story. This will help til developers to pinpoint exactly where to put their efforts. However, accept criteria’s will also help the users and customers to check if what they requested 6 months ago has been implemented, and it will eliminate scope creep as well.

An example of accept criteria’s for the user story regarding printing the festival program which we looked at earlier could be.

  • Accept criteria 1: The entire program should be printable.
  • Accept criteria 2: The program should fit the paper size available in the printer.
  • Accept criteria 3: Pictures of the performers should be included if they are available on the website.
  • Accept criteria 4: The Festival logo should be in the top right-hand corner of each page printed.

Imaging how simple it is to test a solutions by simply checking the accept criteria’s before you can sign it of to production.

Reporting to your Sterring Committee

Jan Schwaner
Facebooktwitterredditpinterestlinkedintumblrmail
Steering Committee reporting
Steering Committee reporting

Reporting to your steering committee might be the one thing that you should always give your full attention. These are the people who expects you to handle their project and make sure that it is steered safely to target… And if they do not trust you, they might replace you. Therefor you should never try to hide risks, issues, budget problems or milestone changes. Get it out into the open so that they know you need their help.

Your report has three functions that you should always keep in mind;

  1. It should give the steering committee a complete overview of the state of your project.
  2. It should give the steering committee the ability to focus their efforts on project issues that needs their attention.
  3. And it should give the steering committee the ability to make calculated decisions in regards to the projects issues.

When to report?

If possible, you should send a report to the steering committee once a week – You can help yourself and make it a reoccurring event in your calendar.
You might have steering committee meetings once every two week, once every month or similar, all depending on your project, but you should always make sure that the steering committee receives the report at least 24 hours before the next meeting.

Sending the report at least once a week, means that you need to keep it short and effective. No one will read a 10 page report if it is send every week… Besides, you would end up doing nothing but writing reports. Instead, keep your report to a maximum of two pages and whenever possible communicate in KPI’s and bullet points.
Things that you need to include but can’t be kept at two pages should be put in as an appendix – E.g. a timetable, burn down charts, financial reports etc.

What should go in a steering committee report.

So, what should go in a report. Well, there are seven things you need to focus on as a minimum. These are:

  • Executive summary.
    Make sure the report always have a KPI summary at the top of page one, to give an overview of where there might be problems that needs the committee focus. E.g., budget changes, changes to milestones and so forth.
  • Progress.
    Here you should make an indication of resources spent to date, how many resources are needed before you are done and how this adds up to your original estimates. Let the steering committee whether or not you are on track.
  • Budget.
    Present a statues of your current budget situation and your expectations – calculate how much is spent to date and add it to the remaining budget for completing the project. Afterwards compare it to the budget previously approved by the steering committee – Do you lack funds then let them know.
  • Timeline.
    Only put in a description of the changes that has been done to the timeline since your last meeting – And keep the entire timetable as an appendix to the report. If no changes has been done since the last meeting, you should put in the report “no changes done” and leave the timetable out.
  • Resources.
    Does the project have the right resources? Do you need a person with a special set of skills? Do you have enough resources to complete on time? (e.g., you have 3 developers but need 7 to make the deadline). Also, let the steering committee know if you have resources that aren’t useful to your project, so that they can be put to other tasks and doesn’t drain your budget (e.g. you have five digitale designers but only need one of them part time).
  • Risks.
    Here should go the five biggest threats to your project, which you have not handled yet. There might be several more risks to your project, but you should only put in the five most pressing.
  • The project managers concerns
    This is where you as a project manager can rise concerns that you can’t really relate to the focus points above – E.g., the steering committee needs to meet once a week instead of every month or maybe lack of input from the accounting department on expenses is becoming a problem in your reporting etc. In other words , this is where you can tell the committee things that affect your project, but is not a direct risk to it.

Download a report template here >>>

Mind your estimates

Jan Schwaner
Facebooktwitterredditpinterestlinkedintumblrmail
Planning poker
Planning poker

Estimating your project is the key to figure out how many resources a project needs in order to complete successfully. But estimates are also the key to measure whether everything goes as planned.

The estimate will give the steering committee or a potential client the ability to judge whether a project is worth implementing or not. In addition, if estimates are given to specific user demands (aka userstories), then the product owner/client/customer can make a judgment of whether a specific demand will give enough value to justify the expenses.

Doing estimates, both rough in the start of a project and detailed estimates later on, will give the ability to prove that the project is doing progress, if your estimates are over or under your budgets, if your deadline and milestones can be meet and so forth. There are various ways of doing this and numerous tools that can help you do it.

How to estimate?
There are two ways that I find especially useful when estimating tasks. One is by using hours and days and the other is by using points and complexity.

If estimates are done in hours or days, then the team members probably will have to breakdown the task and give their estimate on the tasks by telling the SCRUM master or project manager how many hours they would need to complete a subtask. Then adding up all the estimates will give the estimate for the entire userstory and then the estimate for the entire project.

However, breaking down every userstory before being able to give an estimate for an entire project might in some cases be too big a task to make sense (you don’t wanna spent weeks estimating a project that the customer don’t want you to do. In that case you can estimate the userstories by given them points or by rating their complexity. Once that is done, you can breakdown and estimate 2 – 4 userstories in each category, find the average time estimated for a complexity and then sum them all up.

An example.
You have 500 userstories in your project. You go through each userstory and give them points on the following in scale

  • 0 Points (No work needed)
  • 5 points (Being the simplest)
  • 20 points
  • 50 points
  • 100 points
  • Over 100 points

Once that is done, you will need to pick 4 userstories from each scale, break them down and estimate them thoroughly. Afterwards you will need to find the average of the estimates given for each scale and then multiply that amount of hours by the number of userstories in that complexity category. Once that is done, you can add up all the hours from each scale and you will have a descent idea about the resources you will need in order to finish your project.

Always follow up
You should always follow up on your estimates to see if they hold – Usually they do not, so beware of this. When you can see a trend in your estimates, you should try to figure out how much they deviate, and make sure to adjust the estimates for the rest of the backlog.

Once you do recognize that your estimates are off, you should recalculate the entire budget for the project. E.g. If all the tasks you complete has a 30% higher use of hours spent than what they was estimated for, then you should adjust your estimates accordingly by adding 30% to the remaining backlog, and then make sure to report your new budget to your steering committee and/or product owner and customer.

Budget in an agile project.

Jan Schwaner
Facebooktwitterredditpinterestlinkedintumblrmail
Budget in agile projects
Budget in agile projects

When doing an agile project, you are doing a project with great many uncertainties. How do one create a budget for a task that has not been specified yet? Whether you say “Agile!” or not, your stakeholders will need some kind of indication on whether their expectations can be meet within budget, or whether they should look at which part of the project that can be excluded – Or maybe the project should be shot down?

Know your budget

First step is to figure out how much money and resources the project owner is ready to spend on the project. Next step is to do an extremely high-level estimation to see if it is possible to meet the budget and the expectation for the product. If you want to do a simple website and are ready to spent 5,000 $ then you are probably going to succeed. If you want to build a complete virtual 3D avatar chat program for the same amount, then you are probably facing a bit of a challenge.

In addition, you need to know what deviation is acceptable for you handle, without consulting you project owner or steering committee. E.g., you as a project manager can approve a deviation of up to +10% of the full budget.

Estimate, and then re-estimate, and then re-estimate…

Next you need to do estimates for the tasks at hand – If you are in the idea phase of the project, then you are probably planning to do a couple of workshops or other activities that will bring you closer to the next phase of your project.

A role of thumb is that the expenses of a it-development project will split as follows on a 6 phased project (Please note – THIS IS ONLY A RULE OF THUMB, IT ALL DEPENDS ON YOUR PROJECT, and I strongly advise you to check passed experiences in the field of Development that you are project managing in).

  • 10 % for the Idea phase.
  • 20 % for the analysis phase.
  • 40 % for the implementation phase.
  • 20 % for the test phase.
  • 10 % for the release phase.

These percentages will also help you to predict if your project is going to meet budget or not. Again if you have 5,000 $ for your project, and you estimate to spent 1,500 $ on your idea phase, then you probably will need some more funding for your project – Or scale down the scope.

For each phase, you should do a complete estimate of all the tasks before you start the phase (and the tasks). Therefore, before you start developing you need to breakdown and estimate all requirements for the new product.

Monitoring your budgets

Once your estimates are in place, and the project is on the way, you need to monitor your estimates versus your actual expenses. If you see that most task has been underestimated and you spent an average of + 20 % on all tasks, then you will need to do adjustments to your estimates and budget asap, and make sure to report this change to your steering committee, so that they can decide how to handle these new numbers.

Development as a service?

Jan Schwaner
Facebooktwitterredditpinterestlinkedintumblrmail

gearIf you are working in software development, then you have probably heard the terms “Continues delivery” and “DevOps”. These are not just new buzz-words, they are already being used in varies software companies, including some of the really big players on the market.

These new methods aims for releases of software on a daily and sometimes even hourly basis. This is done to ensure that the product is pushed to the market as fast and possible, and then to get the feedback from the end user and make adjustment to the product accordingly.

This way of developing software moves the actual development to be more like a service rather than a project, and in most know cases, this approach to software development is for companies developing for the end consumer market (e.g. Facebook, Google etc.), but more and more “non end user IT companies” are looking into this method.

This way of developing software raises all sorts of new questions for our way to approach software development as projects, which has a budget, a deadline and a clear scope and so forth. If you don’t have a finale specification for your product and thereby not knowing when exactly you are done? How then will you do estimates, manage budget, set timetables, measure progress and all these other mechanisms that ensures that your project don’t go of track?

The answer for this comes in varies forms, but the one thing that you need to embrace is that you will have to see the development as a service organization and not as a project. So basicly you will have to figure out how important the software product is to your organization or client, and how many resources you will throw at it. If the software product is your core business, then it might be worth to put as much focus on the development team as possible, but if the software is not your main product but only a support to the business, then you might wanna go the old fashion way at set a max amount of money that you are willing to spent.

Change management in agile projects

Jan Schwaner
Facebooktwitterredditpinterestlinkedintumblrmail

change-managementEvery now and again I get the question – How will you manage changes in the project, if it is agile? Most of the time I would like to be able to answer ”I don’t, agile means constant changes, and I’ll manage the changes by doing the project in an agile manner”. However life as a project manager isn’t always that easy.

In almost every project of a foreseeable size, you will eventually get to the point where the Steering Committee or your project owner want to know who decided to do a specific thing in the project you are managing. If you do things agile and don’t keep track of your changes, then you probably can’t answer that question – ”Who decided to use a top menu and not the left side menu that we planned to use right from the start”? Try and answer that question after 4 months of agile development with absolutely no change logs.

So how can you handle changes – Well, there are a couple of different ways, but they all involve using a log. If your project is done agile, then chances are that you are using user stories (if not, then you should try it out, it is awesome). If you are using user stories you can add a log to each user story, and simply keep track of what has been decide by whom, when it was decided and why. Then later on you can access that user story in order to answer why the menu was changed.
A word of caution, some SCRUM tools makes it had to access the items that has been completed and approved during your project. Always make sure that you can access old user stories and sprint logs in the SCRUM tool that you use.

A second way to handle this is by doing a good old fashion change log, however you should not do any long description in change management documents, or else you will drown in paperwork. In stead use a simple spreadsheet with at least the following columns:

  • ID number
  • Date for deciding to do the change
  • User story identification number
  • User story title
  • Description of what has been changed and why.
  • Who decided this.
  • What impact is expect to the project if any.

The third way, and that is for the spoiled project managers, is to have your product owner do the change management for you, but basically he or she will probably do it in the same fashion as described above, or else that person will be the one who will be drowning in paperwork.

Estimation and impact on the project
When doing changes to a project, even if it is agile, you should always make sure that the tasks are re-estimated and you need to know exactly what impact the change will have on your project – What seems like a simple twist in a steering committee meeting may have a big impact on the project when you present it to your developers. Therefor, you should never allow a change to be decided/approved/committed before you’ve got a complete overview of the impact AND are able to explain this to the rest of the project group.

Roles and responsibility

Jan Schwaner
Facebooktwitterredditpinterestlinkedintumblrmail

the-broken-chain1Knowing who is who in your project is alpha and omega when communicating to your stakeholders, but more important is to know who is responsible for what – Call it your chain of command if you like, or who to turn to when things start to turn bad.

Below you will find a short description of the 4 roles, that is the minimum you need to assign to your project. There might be other roles and responsibilities that you need to assign, but the four roles below should always be assigned.

Project owner
So what roles should be assigned in a project. First of you need a project owner, who is financial responsible for the project – This is “The big dog in the kennel”, and he or she will be ultimately responsible for the entire project and its success. This person is the one paying the bills, and therefor he or she can ultimately add more resource to the project and save you if needs, change the scope of the project by removing tasks or maybe even close down your project if expenses are too high.

Project manager
The next in the chain of command is the project manager(s). There can be one or more project managers to a project, e.g. if you are doing a project for a customer, then there can be a project manager at the supplier and at the customer. The project manager(s) are responsible for the day-to-day management of the project, and they report directly to the project owner and the other stakeholders, including the steering committee. Reporting can include things like finances, progress, risks, deadlines and other issues – Basically what the steering committee and the Project owner needs in order to make the right decisions.

Product owner
The product owner is responsible for creating and updating the project backlog (which is the list of tasks that sums up your project). The product owner need to know his/hers product well enough to prioritize, update and maybe even remove items from the backlog. He or she is also responsible for creating the sprint backlog, which focuses on the tasks that is to be included in the sprint at hand and the upcoming sprints (see previous blog post on the Product owners rule in scrum projects).

Scrum master
A project (if agile) can have one or more Scrum Masters. The Scrum Masters role is to make sure that the day-to-day progress of the project is running smoothly. This role is normally given to one of the senior developers on each development team. It is the SCRUM master obligation to report any problems that the team can handle to the project manager and product owner, but also he or she needs to make sure that the development runs smoothly on the day-to-day basis.

Resources
The resources that you need varies from project to project. Since this website focuses on IT projects, then you will probably one or more developers or technically personalities, but resources can also be designers, architects, legal advise, security, machinery, buildings, servers and so forth.

It really depends on the project at hand, however there should be no doubt, when it comes to day to day business then the resources needs to know what they are supposed to build, not how to build it, in what order to build it and so forth. If you are a project owner, project manager, product owner or the scrum master, it is extremely important that you focuses on facilitating the project, support the resources and make sure that everybody is moving in the right direction.